From missa at openjdk.org Sat Nov 1 21:15:35 2025 From: missa at openjdk.org (Mohamed Issa) Date: Sat, 1 Nov 2025 21:15:35 GMT Subject: RFR: 8371088: Build fails when trying hsdis option Message-ID: When compiling the **install-hsdis** target, _libsframe.a_ won't be linked on some Linux distros (e.g., openSUSE Leap v15.6) because it's in the _lib64_ folder. This change adds a check for that so the build doesn't fail. To test, I used the configure and build commands posted below. bash ./configure --with-boot-jdk=/opt/jvm/java-25-openjdk --with-boot-jdk-jvmargs="-Xmx8G" --with-jmh=build/jmh/jars --with-hsdis=binutils --with-binutils-src=~/git/sourceware.org/binutils-gdb --with-jtreg=~/github/missa-prime/openjdk/jtreg/build/images/jtreg --with-gtest=~/github/missa-prime/google/googletest --with-debug-level=fastdebug make CONF=linux-x86_64-server-fastdebug clean make CONF=linux-x86_64-server-fastdebug install-hsdis ------------- Commit messages: - Add check for lib64 library to pick up libsframe.a in hsdis build Changes: https://git.openjdk.org/jdk/pull/28099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371088 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28099/head:pull/28099 PR: https://git.openjdk.org/jdk/pull/28099 From prr at openjdk.org Sun Nov 2 17:38:07 2025 From: prr at openjdk.org (Phil Race) Date: Sun, 2 Nov 2025 17:38:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v3] In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 14:35:46 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust comment @azvegint please review ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3478133421 From vyazici at openjdk.org Mon Nov 3 10:09:29 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 3 Nov 2025 10:09:29 GMT Subject: RFR: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Wed, 29 Oct 2025 17:23:28 GMT, Daniel Fuchs wrote: > The only other mention of sdp I could find in the sources and test is in `ct.properties` @dfuch, `ct.properties` is used by `javac -source 8`, and hence, should not be updated. Nevertheless, good that you raised this detail. I've created [JDK-8371133](https://bugs.openjdk.org/browse/JDK-8371133) to demystify it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28012#issuecomment-3479757650 From erikj at openjdk.org Mon Nov 3 13:03:31 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 3 Nov 2025 13:03:31 GMT Subject: RFR: 8371088: Build fails when trying hsdis option In-Reply-To: References: Message-ID: On Sat, 1 Nov 2025 21:08:57 GMT, Mohamed Issa wrote: > When compiling the **install-hsdis** target, _libsframe.a_ won't be linked on some Linux distros (e.g., openSUSE Leap v15.6) because it's in the _lib64_ folder. This change adds a check for that so the build doesn't fail. > > To test, I used the configure and build commands posted below. > > > bash ./configure --with-boot-jdk=/opt/jvm/java-25-openjdk --with-boot-jdk-jvmargs="-Xmx8G" --with-jmh=build/jmh/jars --with-hsdis=binutils --with-binutils-src=~/git/sourceware.org/binutils-gdb --with-jtreg=~/github/missa-prime/openjdk/jtreg/build/images/jtreg --with-gtest=~/github/missa-prime/google/googletest --with-debug-level=fastdebug > > make CONF=linux-x86_64-server-fastdebug clean > > make CONF=linux-x86_64-server-fastdebug install-hsdis Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28099#pullrequestreview-3410933469 From erikj at openjdk.org Mon Nov 3 14:17:15 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 3 Nov 2025 14:17:15 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v9] In-Reply-To: References: Message-ID: <5uVrChmuvWYTVm5OgP-PoYFS-Sg3YkEVaUB8q9lIMqE=.8eab6e42-19e3-4a0d-bb62-d16c362ed670@github.com> On Fri, 31 Oct 2025 22:48:53 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Minor doc/comment clean-ups >From a build point of view this is definitely starting to look better. I would like to get input from a reviewer in the component team at this point to comment on the validity of the change before I spend more time reviewing the build aspects. make/autoconf/lib-krb5.m4 line 47: > 45: KRB5_FOUND=no > 46: > 47: if test "x${with_krb5}" != "x" && test "x${with_krb5}" != "xyes" && test "x${with_krb5}" != "xauto"; then I think you missed the case where `${with_krb5}` is `no`. make/autoconf/lib-krb5.m4 line 132: > 130: AC_MSG_RESULT([$KRB5_FOUND]) > 131: else > 132: PKG_CHECK_MODULES(KRB5, krb5, [KRB5_FOUND=yes], [KRB5_FOUND=no]) In lib-freetype.m4 we first check if `PKG_CONFIG` has a value before trying to use it. We also print a result because it seems PKG_CHECK_MODULES is quiet. I tried your patch here and configure doesn't produce any output in this case, so I think we should print something. make/modules/java.security.jgss/Lib.gmk line 101: > 99: > 100: ifeq ($(call isTargetOs, linux), true) > 101: ifeq ($(ENABLE_LIBLINUXKRB5), true) Suggestion: ifeq ($(ENABLE_LIBKRB5_LINUX), true) ------------- PR Review: https://git.openjdk.org/jdk/pull/28075#pullrequestreview-3411106519 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486542040 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486621470 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2486550921 From mbaesken at openjdk.org Mon Nov 3 15:28:10 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 3 Nov 2025 15:28:10 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v2] In-Reply-To: References: <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com> <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com> Message-ID: On Thu, 30 Oct 2025 15:41:06 GMT, Matthias Baesken wrote: > For those libs where we set LTO = true, we can add a global on/off configure arg to enable this. This way, we do not cause issues for distributors because still the configure flag must be set For Hotspot / libjvm we have currently `--enable-jvm-feature-link-time-opt` ; maybe we should introduce something similar named for the JDK libs where we choose lto? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3481107407 From jlahoda at openjdk.org Mon Nov 3 17:06:36 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 3 Nov 2025 17:06:36 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain In-Reply-To: References: Message-ID: On Thu, 4 Sep 2025 15:22:57 GMT, Archie Cobbs wrote: > When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. > > This can create a trap for the unwary, as in this example: > > public long readLongBigEndian(byte[] buf, int offset) { > return ((buf[offset + 0] & 0xff) << 56) // BUG HERE > | ((buf[offset + 1] & 0xff) << 48) // BUG HERE > | ((buf[offset + 2] & 0xff) << 40) // BUG HERE > | ((buf[offset + 3] & 0xff) << 32) // BUG HERE > | ((buf[offset + 4] & 0xff) << 24) > | ((buf[offset + 5] & 0xff) << 16) > | ((buf[offset + 6] & 0xff) << 8) > | ((buf[offset + 7] & 0xff); > } > > This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`. I think overall seems sensible - some questions/nits inline. make/jdk/src/classes/build/tools/intpoly/FieldGen.java line 631: > 629: + (params.getBitsPerLimb() - 1) + ";"); > 630: if (params.getBitsPerLimb() * params.getNumLimbs() != params.getPower()) { > 631: result.appendLine("@SuppressWarnings(\"lossy-conversions\")"); Do you know what is the specific problematic code generated here? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4055: > 4053: int maximumShift; > 4054: switch (((OperatorSymbol)operator).opcode) { > 4055: case ByteCodes.ishl: Nit: use "modernized" switch - multiple case labels and `->`? test/langtools/tools/javac/lint/ShiftOutOfRange.java line 14: > 12: > 13: // These should generate warnings > 14: a = a << (byte)-1; Looking at the patch, I am not completely convinced disallowing `-1` is beneficial. On one hand, it looks weird. On the other hand, it makes some sense (as far as I can tell, it is universal for both `int` and `long`). And, unlike `128`, it is not clearly wrong. I am not sure if it wouldn't be better to simply permit `-1` as a special case. I see there are `<< -5` in the microbenchmark tests, but I think I am less inclined to accommodate negative values other than `-1`, as the semantics of those is much more cryptic, for me at least. Please let me know what you think. ------------- PR Review: https://git.openjdk.org/jdk/pull/27102#pullrequestreview-3411950069 PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487162366 PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487161036 PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487176078 From rgiulietti at openjdk.org Mon Nov 3 18:12:13 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 3 Nov 2025 18:12:13 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 16:47:56 GMT, Jan Lahoda wrote: >> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. >> >> This can create a trap for the unwary, as in this example: >> >> public long readLongBigEndian(byte[] buf, int offset) { >> return ((buf[offset + 0] & 0xff) << 56) // BUG HERE >> | ((buf[offset + 1] & 0xff) << 48) // BUG HERE >> | ((buf[offset + 2] & 0xff) << 40) // BUG HERE >> | ((buf[offset + 3] & 0xff) << 32) // BUG HERE >> | ((buf[offset + 4] & 0xff) << 24) >> | ((buf[offset + 5] & 0xff) << 16) >> | ((buf[offset + 6] & 0xff) << 8) >> | ((buf[offset + 7] & 0xff); >> } >> >> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`. > > test/langtools/tools/javac/lint/ShiftOutOfRange.java line 14: > >> 12: >> 13: // These should generate warnings >> 14: a = a << (byte)-1; > > Looking at the patch, I am not completely convinced disallowing `-1` is beneficial. On one hand, it looks weird. On the other hand, it makes some sense (as far as I can tell, it is universal for both `int` and `long`). And, unlike `128`, it is not clearly wrong. I am not sure if it wouldn't be better to simply permit `-1` as a special case. > > I see there are `<< -5` in the microbenchmark tests, but I think I am less inclined to accommodate negative values other than `-1`, as the semantics of those is much more cryptic, for me at least. > > Please let me know what you think. One way to read `v << -n` is: "Shift out everything to the left, except for the `n` least significant bits". Analogously for `v >>> -n`: "Shift out everything to the right, except for the `n` most significant bits". To rotate `v` by `n` bits to the left, for example, one can write `v << n | v >>> -n` (regardless of the width of `v`) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487416183 From acobbs at openjdk.org Mon Nov 3 18:36:33 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 3 Nov 2025 18:36:33 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: References: Message-ID: > When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. > > This can create a trap for the unwary, as in this example: > > public long readLongBigEndian(byte[] buf, int offset) { > return ((buf[offset + 0] & 0xff) << 56) // BUG HERE > | ((buf[offset + 1] & 0xff) << 48) // BUG HERE > | ((buf[offset + 2] & 0xff) << 40) // BUG HERE > | ((buf[offset + 3] & 0xff) << 32) // BUG HERE > | ((buf[offset + 4] & 0xff) << 24) > | ((buf[offset + 5] & 0xff) << 16) > | ((buf[offset + 6] & 0xff) << 8) > | ((buf[offset + 7] & 0xff); > } > > This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'master' into JDK-5038439 to fix conflict. - Address review comment (combine switch cases). - Merge branch 'master' into JDK-5038439 to fix conflict. - Add "long" as a supported message parameter type. - Use "bit(s)" instead of "bits" where value could be 1. - Merge branch 'master' into JDK-5038439 - Sprinkle more variety into the regression test. - Minor diff cleanup. - Update "lossy-conversions" description in compiler module Javadoc. - Warn for bit shifts using an out-of-range shift amount. ------------- Changes: https://git.openjdk.org/jdk/pull/27102/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=01 Stats: 181 lines in 13 files changed: 173 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/27102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102 PR: https://git.openjdk.org/jdk/pull/27102 From acobbs at openjdk.org Mon Nov 3 18:36:35 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 3 Nov 2025 18:36:35 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: References: Message-ID: <0D_jgs9w47rAKwt5Udla_7C1bfb7Moc14-Fr4RsTq64=.27341088-069f-4208-817e-7391e1348a54@github.com> On Mon, 3 Nov 2025 16:44:13 GMT, Jan Lahoda wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge branch 'master' into JDK-5038439 to fix conflict. >> - Address review comment (combine switch cases). >> - Merge branch 'master' into JDK-5038439 to fix conflict. >> - Add "long" as a supported message parameter type. >> - Use "bit(s)" instead of "bits" where value could be 1. >> - Merge branch 'master' into JDK-5038439 >> - Sprinkle more variety into the regression test. >> - Minor diff cleanup. >> - Update "lossy-conversions" description in compiler module Javadoc. >> - Warn for bit shifts using an out-of-range shift amount. > > make/jdk/src/classes/build/tools/intpoly/FieldGen.java line 631: > >> 629: + (params.getBitsPerLimb() - 1) + ";"); >> 630: if (params.getBitsPerLimb() * params.getNumLimbs() != params.getPower()) { >> 631: result.appendLine("@SuppressWarnings(\"lossy-conversions\")"); > > Do you know what is the specific problematic code generated here? Actually this goes away after merging int the latest master. It was fixed independently by JDK-8368301. > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4055: > >> 4053: int maximumShift; >> 4054: switch (((OperatorSymbol)operator).opcode) { >> 4055: case ByteCodes.ishl: > > Nit: use "modernized" switch - multiple case labels and `->`? We can combined the labels, but since we're setting _two_ values we can't use the `->` syntax. Fixed in 8044632727d. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487476213 PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487476095 From acobbs at openjdk.org Mon Nov 3 18:36:37 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 3 Nov 2025 18:36:37 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 18:09:01 GMT, Raffaello Giulietti wrote: >> test/langtools/tools/javac/lint/ShiftOutOfRange.java line 14: >> >>> 12: >>> 13: // These should generate warnings >>> 14: a = a << (byte)-1; >> >> Looking at the patch, I am not completely convinced disallowing `-1` is beneficial. On one hand, it looks weird. On the other hand, it makes some sense (as far as I can tell, it is universal for both `int` and `long`). And, unlike `128`, it is not clearly wrong. I am not sure if it wouldn't be better to simply permit `-1` as a special case. >> >> I see there are `<< -5` in the microbenchmark tests, but I think I am less inclined to accommodate negative values other than `-1`, as the semantics of those is much more cryptic, for me at least. >> >> Please let me know what you think. > > One way to read `v << -n` is: "Shift out everything to the left, except for the `n` least significant bits". > Analogously for `v >>> -n`: "Shift out everything to the right, except for the `n` most significant bits". > > To rotate `v` by `n` bits to the left, for example, one can write `v << n | v >>> -n` (regardless of the width of `v`) Hmm, obviously this is a judgement call and I'm curious what others think. My opinion is that I still think there should be a warning for shifts of -1. I mean, maybe to a _real_ hacker, then of course `foo << -1` makes perfect sense because it's just stating the "obvious" which is "shift the low order bit into the high order position and set all the other bits to zero", right?? :) I just don't think the average Java programmer automatically understands that. Yes, it's an idiom or "handy trick", but if hasn't attained the status of being universally recognized then it doesn't deserve a special exception. On the other hand, excluding -1 from the warning would be less disruptive (at least, to the real hackers out there), and that has its own merits. So I don't have a super strong opinion about it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487476314 From hgreule at openjdk.org Mon Nov 3 18:36:39 2025 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 3 Nov 2025 18:36:39 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: References: Message-ID: <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com> On Mon, 3 Nov 2025 18:32:57 GMT, Archie Cobbs wrote: >> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. >> >> This can create a trap for the unwary, as in this example: >> >> public long readLongBigEndian(byte[] buf, int offset) { >> return ((buf[offset + 0] & 0xff) << 56) // BUG HERE >> | ((buf[offset + 1] & 0xff) << 48) // BUG HERE >> | ((buf[offset + 2] & 0xff) << 40) // BUG HERE >> | ((buf[offset + 3] & 0xff) << 32) // BUG HERE >> | ((buf[offset + 4] & 0xff) << 24) >> | ((buf[offset + 5] & 0xff) << 16) >> | ((buf[offset + 6] & 0xff) << 8) >> | ((buf[offset + 7] & 0xff); >> } >> >> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Merge branch 'master' into JDK-5038439 to fix conflict. > - Address review comment (combine switch cases). > - Merge branch 'master' into JDK-5038439 to fix conflict. > - Add "long" as a supported message parameter type. > - Use "bit(s)" instead of "bits" where value could be 1. > - Merge branch 'master' into JDK-5038439 > - Sprinkle more variety into the regression test. > - Minor diff cleanup. > - Update "lossy-conversions" description in compiler module Javadoc. > - Warn for bit shifts using an out-of-range shift amount. test/langtools/tools/javac/lint/ShiftOutOfRange.java line 18: > 16: a = a >>> (short)-1; > 17: a <<= -1; > 18: a >>= -1L; // also generates "implicit cast from long to int in compound assignment is possibly lossy" I'm a bit surprised by the additional warning here. The shift still operates on int, not long; i.e., unary promotion is performed for each argument rather than binary promotion https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.19 Should this be fixed (separately, obviously)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487472103 From missa at openjdk.org Mon Nov 3 18:40:59 2025 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 3 Nov 2025 18:40:59 GMT Subject: RFR: 8371088: Build fails when trying hsdis option In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 13:00:31 GMT, Erik Joelsson wrote: >> When compiling the **install-hsdis** target, _libsframe.a_ won't be linked on some Linux distros (e.g., openSUSE Leap v15.6) because it's in the _lib64_ folder. This change adds a check for that so the build doesn't fail. >> >> To test, I used the configure and build commands posted below. >> >> >> bash ./configure --with-boot-jdk=/opt/jvm/java-25-openjdk --with-boot-jdk-jvmargs="-Xmx8G" --with-jmh=build/jmh/jars --with-hsdis=binutils --with-binutils-src=~/git/sourceware.org/binutils-gdb --with-jtreg=~/github/missa-prime/openjdk/jtreg/build/images/jtreg --with-gtest=~/github/missa-prime/google/googletest --with-debug-level=fastdebug >> >> make CONF=linux-x86_64-server-fastdebug clean >> >> make CONF=linux-x86_64-server-fastdebug install-hsdis > > Marked as reviewed by erikj (Reviewer). @erikj79 Is it ok if I mark this for integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28099#issuecomment-3481972739 From duke at openjdk.org Mon Nov 3 18:50:38 2025 From: duke at openjdk.org (Nick Hall) Date: Mon, 3 Nov 2025 18:50:38 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality In-Reply-To: References: Message-ID: <8Usem4e_ob2t8vNthfAQ91duUt2eVCToYUttekAau-o=.b9cc0f2b-38b4-410d-a59a-c6b82a5b9679@github.com> On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`. Thanks for these @erikj79, no idea how I managed to miss at least one of those...! All addressed in latest commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3481997569 From duke at openjdk.org Mon Nov 3 18:50:37 2025 From: duke at openjdk.org (Nick Hall) Date: Mon, 3 Nov 2025 18:50:37 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v10] In-Reply-To: References: Message-ID: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> > _Purpose_ > > This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. > > _Rationale_ > > Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. > > The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). > > Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. > > _Implementation Detail_ > > Note that there were multiple possible ways of doing this: > > 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. > > 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. > > 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. > > I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensate for this. > > Interested to hear if anyone else... Nick Hall has updated the pull request incrementally with one additional commit since the last revision: Address second set of @erikj79's build comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28075/files - new: https://git.openjdk.org/jdk/pull/28075/files/47968fe7..8c8288a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=08-09 Stats: 15 lines in 2 files changed: 10 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075 PR: https://git.openjdk.org/jdk/pull/28075 From acobbs at openjdk.org Mon Nov 3 18:56:27 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 3 Nov 2025 18:56:27 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com> References: <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com> Message-ID: On Mon, 3 Nov 2025 18:30:22 GMT, Hannes Greule wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - Merge branch 'master' into JDK-5038439 to fix conflict. >> - Address review comment (combine switch cases). >> - Merge branch 'master' into JDK-5038439 to fix conflict. >> - Add "long" as a supported message parameter type. >> - Use "bit(s)" instead of "bits" where value could be 1. >> - Merge branch 'master' into JDK-5038439 >> - Sprinkle more variety into the regression test. >> - Minor diff cleanup. >> - Update "lossy-conversions" description in compiler module Javadoc. >> - Warn for bit shifts using an out-of-range shift amount. > > test/langtools/tools/javac/lint/ShiftOutOfRange.java line 18: > >> 16: a = a >>> (short)-1; >> 17: a <<= -1; >> 18: a >>= -1L; // also generates "implicit cast from long to int in compound assignment is possibly lossy" > > I'm a bit surprised by the additional warning here. The shift still operates on int, not long; i.e., unary promotion is performed for each argument rather than binary promotion https://docs.oracle.com/javase/specs/jls/se25/html/jls-15.html#jls-15.19 > > Should this be fixed (separately, obviously)? I agree, this is a separate compiler glitch. I've created [JDK-8371162](https://bugs.openjdk.org/browse/JDK-8371162). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487531814 From rriggs at openjdk.org Mon Nov 3 19:15:13 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 3 Nov 2025 19:15:13 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 18:31:54 GMT, Archie Cobbs wrote: >> One way to read `v << -n` is: "Shift out everything to the left, except for the `n` least significant bits". >> Analogously for `v >>> -n`: "Shift out everything to the right, except for the `n` most significant bits". >> >> To rotate `v` by `n` bits to the left, for example, one can write `v << n | v >>> -n` (regardless of the width of `v`) > > Hmm, obviously this is a judgement call and I'm curious what others think. > > My opinion is that I still think there should be a warning for shifts of -1. > > I mean, maybe to a _real_ hacker, then of course `foo << -1` makes perfect sense because it's just stating the "obvious" which is "shift the low order bit into the high order position and set all the other bits to zero", right?? :) > > I just don't think the average Java programmer automatically understands that. > > Yes, it's an idiom or "handy trick", but if hasn't attained the status of being universally recognized then it doesn't deserve a special exception. > > On the other hand, excluding -1 from the warning would be less disruptive (at least, to the real hackers out there), and that has its own merits. So I don't have a super strong opinion about it. This might be worth a corpus scan to see how common it is to shift by -1 or other constants, either int or long. Someone, might interpret `v << -1` as a right shift, is it more likely to misinterpret it as using more than 5/6 bits of the shift or considering it signed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2487576716 From erikj at openjdk.org Mon Nov 3 21:09:55 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 3 Nov 2025 21:09:55 GMT Subject: RFR: 8371088: Build fails when trying hsdis option In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 13:00:31 GMT, Erik Joelsson wrote: >> When compiling the **install-hsdis** target, _libsframe.a_ won't be linked on some Linux distros (e.g., openSUSE Leap v15.6) because it's in the _lib64_ folder. This change adds a check for that so the build doesn't fail. >> >> To test, I used the configure and build commands posted below. >> >> >> bash ./configure --with-boot-jdk=/opt/jvm/java-25-openjdk --with-boot-jdk-jvmargs="-Xmx8G" --with-jmh=build/jmh/jars --with-hsdis=binutils --with-binutils-src=~/git/sourceware.org/binutils-gdb --with-jtreg=~/github/missa-prime/openjdk/jtreg/build/images/jtreg --with-gtest=~/github/missa-prime/google/googletest --with-debug-level=fastdebug >> >> make CONF=linux-x86_64-server-fastdebug clean >> >> make CONF=linux-x86_64-server-fastdebug install-hsdis > > Marked as reviewed by erikj (Reviewer). > @erikj79 Is it ok if I mark this for integration? Yes, my review is sufficient. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28099#issuecomment-3482602895 From eosterlund at openjdk.org Mon Nov 3 21:10:00 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 3 Nov 2025 21:10:00 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v7] In-Reply-To: References: Message-ID: On Thu, 23 Oct 2025 16:06:11 GMT, Ioi Lam wrote: >>> Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`? >> >> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR. > >> > Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`? >> >> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR. > > We have > > > #if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64) > #define INCLUDE_CDS_JAVA_HEAP 1 > > > So we need to make sure it works for 32 bit as well. @iklam does this look okay now? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3482604226 From duke at openjdk.org Mon Nov 3 23:53:02 2025 From: duke at openjdk.org (duke) Date: Mon, 3 Nov 2025 23:53:02 GMT Subject: RFR: 8371088: Build fails when trying hsdis option In-Reply-To: References: Message-ID: On Sat, 1 Nov 2025 21:08:57 GMT, Mohamed Issa wrote: > When compiling the **install-hsdis** target, _libsframe.a_ won't be linked on some Linux distros (e.g., openSUSE Leap v15.6) because it's in the _lib64_ folder. This change adds a check for that so the build doesn't fail. > > To test, I used the configure and build commands posted below. > > > bash ./configure --with-boot-jdk=/opt/jvm/java-25-openjdk --with-boot-jdk-jvmargs="-Xmx8G" --with-jmh=build/jmh/jars --with-hsdis=binutils --with-binutils-src=~/git/sourceware.org/binutils-gdb --with-jtreg=~/github/missa-prime/openjdk/jtreg/build/images/jtreg --with-gtest=~/github/missa-prime/google/googletest --with-debug-level=fastdebug > > make CONF=linux-x86_64-server-fastdebug clean > > make CONF=linux-x86_64-server-fastdebug install-hsdis @missa-prime Your change (at version 1bb1aad954e6615ab5f4b807c0b0a541bba297ac) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28099#issuecomment-3483054471 From iklam at openjdk.org Tue Nov 4 00:09:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 4 Nov 2025 00:09:15 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v14] In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 08:43:45 GMT, Erik ?sterlund wrote: >> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. >> >> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. >> >> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. >> >> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. >> >> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. >> >> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. >> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or... > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Comment update The updated version looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3413414459 From serb at openjdk.org Tue Nov 4 01:10:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 4 Nov 2025 01:10:05 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Thu, 30 Oct 2025 15:48:41 GMT, Matthias Baesken wrote: > When introducing new compiler flags, you need to do one of: Just an idea to think about: would it be possible to share the same variable between the JDK and HotSpot to store these parameters? Even in this discussion, it would highlight that these parameters are not new. Or is it not worth the effort? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3483270323 From missa at openjdk.org Tue Nov 4 02:01:15 2025 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 4 Nov 2025 02:01:15 GMT Subject: Integrated: 8371088: Build fails when trying hsdis option In-Reply-To: References: Message-ID: On Sat, 1 Nov 2025 21:08:57 GMT, Mohamed Issa wrote: > When compiling the **install-hsdis** target, _libsframe.a_ won't be linked on some Linux distros (e.g., openSUSE Leap v15.6) because it's in the _lib64_ folder. This change adds a check for that so the build doesn't fail. > > To test, I used the configure and build commands posted below. > > > bash ./configure --with-boot-jdk=/opt/jvm/java-25-openjdk --with-boot-jdk-jvmargs="-Xmx8G" --with-jmh=build/jmh/jars --with-hsdis=binutils --with-binutils-src=~/git/sourceware.org/binutils-gdb --with-jtreg=~/github/missa-prime/openjdk/jtreg/build/images/jtreg --with-gtest=~/github/missa-prime/google/googletest --with-debug-level=fastdebug > > make CONF=linux-x86_64-server-fastdebug clean > > make CONF=linux-x86_64-server-fastdebug install-hsdis This pull request has now been integrated. Changeset: dadbad0b Author: Mohamed Issa Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/dadbad0bef84f671c8194c84080c760453ecc423 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8371088: Build fails when trying hsdis option Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/28099 From eosterlund at openjdk.org Tue Nov 4 05:14:05 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Tue, 4 Nov 2025 05:14:05 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v14] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 00:05:59 GMT, Ioi Lam wrote: > The updated version looks good to me. Thank you for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3483893308 From vyazici at openjdk.org Tue Nov 4 08:06:47 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 4 Nov 2025 08:06:47 GMT Subject: Integrated: 8366575: Remove SDP support In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici wrote: > Remove support for [SDP] (Sockets Direct Protocol), which has been obsolete for more than a decade ? see [JDK-8366575] for details. Tier1-2 is clear. > > [SDP]: https://docs.oracle.com/javase/tutorial/sdp/sockets/overview.html > [JDK-8366575]: https://bugs.openjdk.org/browse/JDK-8366575 This pull request has now been integrated. Changeset: c1476fca Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/c1476fca9d7a679d32b7b43956638b845d1027cc Stats: 732 lines in 13 files changed: 0 ins; 732 del; 0 mod 8366575: Remove SDP support Reviewed-by: alanb, erikj, jpai, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/28012 From mbaesken at openjdk.org Tue Nov 4 09:23:04 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 09:23:04 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 01:07:28 GMT, Sergey Bylokhov wrote: > > When introducing new compiler flags, you need to do one of: > > Just an idea to think about: would it be possible to share the same variable between the JDK and HotSpot to store these parameters? Even in this discussion, it would highlight that these parameters are not new. Or is it not worth the effort? For the HS build, we set them directly in the makefile and not in the configure m4 files, see https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/make/hotspot/lib/JvmFeatures.gmk#L179 Might indeed make sense to refactor this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3484828679 From jwaters at openjdk.org Tue Nov 4 09:31:48 2025 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 4 Nov 2025 09:31:48 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 09:20:29 GMT, Matthias Baesken wrote: > > > When introducing new compiler flags, you need to do one of: > > > > > > Just an idea to think about: would it be possible to share the same variable between the JDK and HotSpot to store these parameters? Even in this discussion, it would highlight that these parameters are not new. Or is it not worth the effort? > > For the HS build, we set them directly in the makefile and not in the configure m4 files, see > > https://github.com/openjdk/jdk/blob/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/make/hotspot/lib/JvmFeatures.gmk#L179 > > > Might indeed make sense to refactor this. It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3484869603 From mbaesken at openjdk.org Tue Nov 4 10:06:26 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 10:06:26 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 09:29:25 GMT, Julian Waters wrote: >It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ -fuse-linker-plugin -fno-strict-aliasing => JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3485030596 From nbenalla at openjdk.org Tue Nov 4 12:27:43 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Nov 2025 12:27:43 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 Message-ID: Get JDK 27 underway. ------------- Commit messages: - initial commit start-of-JDK-27 Changes: https://git.openjdk.org/jdk/pull/28130/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370890 Stats: 90 lines in 34 files changed: 46 ins; 0 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Tue Nov 4 12:27:43 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Nov 2025 12:27:43 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla wrote: > Get JDK 27 underway. This initial version of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see. The GA release date is accurate. The URL of the JVMLS will be updated in the next commit to be accurate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28130#issuecomment-3485695380 From erikj at openjdk.org Tue Nov 4 13:39:40 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 4 Nov 2025 13:39:40 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 10:02:39 GMT, Matthias Baesken wrote: > > It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. > > The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this > > ``` > JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ > -fuse-linker-plugin -fno-strict-aliasing > => > JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) > ``` Yes, please only define the values once and use the variables in the JVM makefile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3486047759 From hannesw at openjdk.org Tue Nov 4 15:35:32 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 4 Nov 2025 15:35:32 GMT Subject: RFR: 8366094: Sealed graph for nested types creates broken links Message-ID: Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that enclosing types are included in the path of the graph file and therefore must have a matching `../` in the generated link. Fixed graphs for some nested sealed types: - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html) - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html) - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828). ------------- Commit messages: - 8366094: Sealed graph for nested types creates broken links Changes: https://git.openjdk.org/jdk/pull/28134/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28134&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366094 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28134/head:pull/28134 PR: https://git.openjdk.org/jdk/pull/28134 From hannesw at openjdk.org Tue Nov 4 16:17:54 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 4 Nov 2025 16:17:54 GMT Subject: RFR: 8366094: Sealed graph for nested types creates broken links [v2] In-Reply-To: References: Message-ID: > Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that enclosing types are included in the path of the graph file and therefore must have a matching `../` in the generated link. > > Fixed graphs for some nested sealed types: > - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html) > - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html) > - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) > > There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828). Hannes Walln?fer 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/28134/files - new: https://git.openjdk.org/jdk/pull/28134/files/c5f60cc6..eb3c1ec3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28134&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28134&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28134/head:pull/28134 PR: https://git.openjdk.org/jdk/pull/28134 From alanb at openjdk.org Tue Nov 4 16:23:45 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 4 Nov 2025 16:23:45 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v10] In-Reply-To: References: Message-ID: <6-z7Z9kN7MYxCnzup409xtPA-i0tRqdCcyAPzNRWU74=.85889a74-ed39-4592-91f2-eaa1c9c95b95@github.com> On Wed, 17 Sep 2025 14:49:00 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo I went through the two relaunchers and they look okay. (I wasn't initially supportive of doing this but it is pragmatic way to test while in this current hybrid state). ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24380#pullrequestreview-3417403333 From mbaesken at openjdk.org Tue Nov 4 16:24:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 16:24:01 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v4] In-Reply-To: References: Message-ID: <5zPoK0usRsiSMWNj6SoATGuJzQn50TFs4sqxwt9KqaM=.b4fb7d54-7ce9-4c1d-95a8-e5c1b49c88ed@github.com> > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Enable lto for BUILD_LIBSPLASHSCREEN, we could add a separate configure flag if desired ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/de4dbf2b..6adc512d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From mbaesken at openjdk.org Tue Nov 4 16:49:06 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 4 Nov 2025 16:49:06 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Use lto configure flags in hs build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/6adc512d..72ba9ed1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=03-04 Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From darcy at openjdk.org Tue Nov 4 18:47:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 4 Nov 2025 18:47:51 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 In-Reply-To: References: Message-ID: <4YP2knvpGm61PssS9EtEX4W35vd90XLOjgkevNqaBF0=.e5a34d1c-4f3d-407e-b53d-789a97682a0d@github.com> On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla wrote: > Get JDK 27 underway. Looks fine so far. ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3418178547 From nbenalla at openjdk.org Tue Nov 4 20:11:23 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Nov 2025 20:11:23 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v2] In-Reply-To: References: Message-ID: <3cZuldBvytdN_Hu0qlLhUkrCsH5EUlZJ5SEjnF8SLEU=.e76693bd-f6e1-4f8a-9dd5-699c9e4306bf@github.com> > Get JDK 27 underway. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: add missing enum ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/cc1a968e..647904b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Tue Nov 4 20:24:52 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 4 Nov 2025 20:24:52 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v3] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision: update links to JVMS 26 and 27 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/647904b3..b51f2324 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From ihse at openjdk.org Wed Nov 5 09:59:21 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 5 Nov 2025 09:59:21 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v11] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into static-relaunchers - Fix typo - Remove debug code - Use strlen to get literal string lenght - Merge branch 'master' into static-relaunchers - Update based on review - Merge branch 'master' into static-relaunchers - Use ReadFile instead - Merge branch 'master' into static-relaunchers - Remove problemlisting - ... and 13 more: https://git.openjdk.org/jdk/compare/0737a562...a925dc3e ------------- Changes: https://git.openjdk.org/jdk/pull/24380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=10 Stats: 818 lines in 14 files changed: 628 ins; 144 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From ihse at openjdk.org Wed Nov 5 10:39:33 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 5 Nov 2025 10:39:33 GMT Subject: Withdrawn: 8345874: Run make doctor automatically on failed CI builds In-Reply-To: References: Message-ID: <1xTqCwQMMK6bNY8bxvl-jhMqZICr3BKt6_TS0I1tX8c=.5d628c22-6e0b-4363-8eba-cb0e75742e46@github.com> On Mon, 7 Apr 2025 10:02:41 GMT, Magnus Ihse Bursie wrote: > If there is something wrong with the build, the user can run "make doctor". That is hard to do in a CI setting. Instead, if the build environment is detected to be a CI, we should run the doctor automatically in case of a failed build. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24485 From ihse at openjdk.org Wed Nov 5 10:41:05 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 5 Nov 2025 10:41:05 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v12] In-Reply-To: References: Message-ID: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Use size_t for string lengths - Also quote the executable name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24380/files - new: https://git.openjdk.org/jdk/pull/24380/files/a925dc3e..dd8919a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24380&range=10-11 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24380/head:pull/24380 PR: https://git.openjdk.org/jdk/pull/24380 From ihse at openjdk.org Wed Nov 5 10:41:07 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 5 Nov 2025 10:41:07 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: <3Y3RYCDUDZQXtNpoBeR65eZSgZ_JpJjwmTdI2ShHMJc=.3b752647-d561-4d42-910b-c7614b03cdfe@github.com> On Mon, 15 Sep 2025 16:37:18 GMT, Alan Bateman wrote: >> Right now, the static-jdk image is a bit strange in that it's a modular run-time image but with all native code compiled into bin/java. In time we hope that jlink will be able to create a static image where everything is in the single executable, so no bin directory (or any directory) for launchers. I don't object to doing something to help testing the intermediate step, just not sure that main line is the right place for this. >> >> As regards the shim when I wonder if it should use CreateProcessW but maybe it doesn't matter for the test environments where they will run. > >> @AlanBateman @jianglizhou Now that Erik has approved the build functionality, I'd appreciate if anyone of you could approve as well, then I can finally integrate this. > > I think it's okay, and good for testing. I went through the relauncher closely, just not 100% sure of the quoting in the Windows implementation so I'm hoping Roger will have a few mins to scan that function. @AlanBateman I updated the PR with a fix for the issue Roger found about quoting the executable name. Can you please re-approve? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24380#issuecomment-3490429458 From ihse at openjdk.org Wed Nov 5 10:41:10 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 5 Nov 2025 10:41:10 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v9] In-Reply-To: References: Message-ID: On Mon, 15 Sep 2025 17:29:59 GMT, Roger Riggs wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove debug code > > src/java.base/windows/native/launcher/relauncher.c line 153: > >> 151: } >> 152: >> 153: // Our executable name (should not be quoted) > > ok here, because the full path is being explicitly passed to CreateProcess. > If the command line is to be parsed and the executable path contains a space, CreateProcess does say it should be quoted. It would be good to have a test case with a space in the executable path. @RogerRiggs I fixed so that the launcher name is also quoted, and verified that it works as it should. Thanks for pointing it out! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24380#discussion_r2493891717 From alanb at openjdk.org Wed Nov 5 11:32:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 5 Nov 2025 11:32:07 GMT Subject: RFR: 8346719: Add relaunchers to the static JDK image for missing executables [v12] In-Reply-To: References: Message-ID: <66QgNnDkrSei0QThaCX_U-qVGiNRstbOLhDeptZVLuo=.af677780-2161-4993-9e12-b866545fdf33@github.com> On Wed, 5 Nov 2025 10:41:05 GMT, Magnus Ihse Bursie wrote: >> In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. >> >> The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Use size_t for string lengths > - Also quote the executable name Thanks, I assume you'll run all the tiers with build targets before integrating. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24380#pullrequestreview-3421402845 From ihse at openjdk.org Wed Nov 5 14:01:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 5 Nov 2025 14:01:04 GMT Subject: Integrated: 8346719: Add relaunchers to the static JDK image for missing executables In-Reply-To: References: Message-ID: On Wed, 2 Apr 2025 14:54:35 GMT, Magnus Ihse Bursie wrote: > In the static JDK image, a single humongous java executable is generated, and no other launcher, such as javac. This makes it impossible to run our jtreg tests, which assume these are present. > > The solution is fortunately simply: we just need to add a bunch of trivial launchers, which are thin wrappers that execute the main java binary, with the proper arguments. This will result in the same behavior as the normal dynamic launchers, only that we will need to take the detour of launching another process instead of calling directly into the JLI library. This pull request has now been integrated. Changeset: 2dd15cf5 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/2dd15cf5bf1614e4b74ad9675723562e14ced8ab Stats: 822 lines in 14 files changed: 632 ins; 144 del; 46 mod 8346719: Add relaunchers to the static JDK image for missing executables Reviewed-by: alanb, erikj ------------- PR: https://git.openjdk.org/jdk/pull/24380 From jlahoda at openjdk.org Wed Nov 5 15:07:34 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 5 Nov 2025 15:07:34 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: <0D_jgs9w47rAKwt5Udla_7C1bfb7Moc14-Fr4RsTq64=.27341088-069f-4208-817e-7391e1348a54@github.com> References: <0D_jgs9w47rAKwt5Udla_7C1bfb7Moc14-Fr4RsTq64=.27341088-069f-4208-817e-7391e1348a54@github.com> Message-ID: On Mon, 3 Nov 2025 18:31:48 GMT, Archie Cobbs wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 4055: >> >>> 4053: int maximumShift; >>> 4054: switch (((OperatorSymbol)operator).opcode) { >>> 4055: case ByteCodes.ishl: >> >> Nit: use "modernized" switch - multiple case labels and `->`? > > We can combined the labels, but since we're setting _two_ values we can't use the `->` syntax. Fixed in 8044632727d. Having two assignments should not be a blocker for `->`, no? It ought to be enough to use `{}`: switch (((OperatorSymbol)operator).opcode) { case ByteCodes.ishl, ByteCodes.ishr, ByteCodes.iushr, ByteCodes.ishll, ByteCodes.ishrl, ByteCodes.iushrl -> { targetType = syms.intType; maximumShift = 32; } case ByteCodes.lshl, ByteCodes.lshr, ByteCodes.lushr, ByteCodes.lshll, ByteCodes.lshrl, ByteCodes.lushrl -> { targetType = syms.longType; maximumShift = 64; } default -> { return; } } I am not strictly insisting on using `->`, but it generally makes things simpler as there's guaranteed no fallthrough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2494960651 From jlahoda at openjdk.org Wed Nov 5 15:17:06 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 5 Nov 2025 15:17:06 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v2] In-Reply-To: References: <0D_jgs9w47rAKwt5Udla_7C1bfb7Moc14-Fr4RsTq64=.27341088-069f-4208-817e-7391e1348a54@github.com> Message-ID: On Wed, 5 Nov 2025 15:05:09 GMT, Jan Lahoda wrote: >> We can combined the labels, but since we're setting _two_ values we can't use the `->` syntax. Fixed in 8044632727d. > > Having two assignments should not be a blocker for `->`, no? It ought to be enough to use `{}`: > > switch (((OperatorSymbol)operator).opcode) { > case ByteCodes.ishl, ByteCodes.ishr, ByteCodes.iushr, > ByteCodes.ishll, ByteCodes.ishrl, ByteCodes.iushrl -> { > targetType = syms.intType; > maximumShift = 32; > } > case ByteCodes.lshl, ByteCodes.lshr, ByteCodes.lushr, > ByteCodes.lshll, ByteCodes.lshrl, ByteCodes.lushrl -> { > targetType = syms.longType; > maximumShift = 64; > } > default -> { > return; > } > } > > > I am not strictly insisting on using `->`, but it generally makes things simpler as there's guaranteed no fallthrough. The `->` can be used, even when having general statements/multiple assignments/etc. - just wrap the code with `{}`, no? switch (((OperatorSymbol)operator).opcode) { case ByteCodes.ishl, ByteCodes.ishr, ByteCodes.iushr, ByteCodes.ishll, ByteCodes.ishrl, ByteCodes.iushrl -> { targetType = syms.intType; maximumShift = 32; } case ByteCodes.lshl, ByteCodes.lshr, ByteCodes.lushr, ByteCodes.lshll, ByteCodes.lshrl, ByteCodes.lushrl -> { targetType = syms.longType; maximumShift = 64; } default -> { return; } } I am not strictly insisting on using `->` but it is typically easier to reason about switches that are guaranteed to not have fallthrough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2495005451 From acobbs at openjdk.org Wed Nov 5 15:26:10 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 5 Nov 2025 15:26:10 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v3] In-Reply-To: References: Message-ID: > When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. > > This can create a trap for the unwary, as in this example: > > public long readLongBigEndian(byte[] buf, int offset) { > return ((buf[offset + 0] & 0xff) << 56) // BUG HERE > | ((buf[offset + 1] & 0xff) << 48) // BUG HERE > | ((buf[offset + 2] & 0xff) << 40) // BUG HERE > | ((buf[offset + 3] & 0xff) << 32) // BUG HERE > | ((buf[offset + 4] & 0xff) << 24) > | ((buf[offset + 5] & 0xff) << 16) > | ((buf[offset + 6] & 0xff) << 8) > | ((buf[offset + 7] & 0xff); > } > > This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`. Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision: - Use -> in switch statement. - Update copyright year. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27102/files - new: https://git.openjdk.org/jdk/pull/27102/files/021e0fb3..89fe2fb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=01-02 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102 PR: https://git.openjdk.org/jdk/pull/27102 From acobbs at openjdk.org Wed Nov 5 15:26:11 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 5 Nov 2025 15:26:11 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v3] In-Reply-To: References: <0D_jgs9w47rAKwt5Udla_7C1bfb7Moc14-Fr4RsTq64=.27341088-069f-4208-817e-7391e1348a54@github.com> Message-ID: On Wed, 5 Nov 2025 15:14:49 GMT, Jan Lahoda wrote: >> Having two assignments should not be a blocker for `->`, no? It ought to be enough to use `{}`: >> >> switch (((OperatorSymbol)operator).opcode) { >> case ByteCodes.ishl, ByteCodes.ishr, ByteCodes.iushr, >> ByteCodes.ishll, ByteCodes.ishrl, ByteCodes.iushrl -> { >> targetType = syms.intType; >> maximumShift = 32; >> } >> case ByteCodes.lshl, ByteCodes.lshr, ByteCodes.lushr, >> ByteCodes.lshll, ByteCodes.lshrl, ByteCodes.lushrl -> { >> targetType = syms.longType; >> maximumShift = 64; >> } >> default -> { >> return; >> } >> } >> >> >> I am not strictly insisting on using `->`, but it generally makes things simpler as there's guaranteed no fallthrough. > > The `->` can be used, even when having general statements/multiple assignments/etc. - just wrap the code with `{}`, no? > > > switch (((OperatorSymbol)operator).opcode) { > case ByteCodes.ishl, ByteCodes.ishr, ByteCodes.iushr, > ByteCodes.ishll, ByteCodes.ishrl, ByteCodes.iushrl -> { > targetType = syms.intType; > maximumShift = 32; > } > case ByteCodes.lshl, ByteCodes.lshr, ByteCodes.lushr, > ByteCodes.lshll, ByteCodes.lshrl, ByteCodes.lushrl -> { > targetType = syms.longType; > maximumShift = 64; > } > default -> { > return; > } > } > > > I am not strictly insisting on using `->` but it is typically easier to reason about switches that are guaranteed to not have fallthrough. > Having two assignments should not be a blocker for `->`, no? It ought to be enough to use `{}`: Duh - of course you're right. Fixed in 89fe2fb1f93. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2495043399 From jlahoda at openjdk.org Wed Nov 5 15:28:57 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 5 Nov 2025 15:28:57 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v3] In-Reply-To: References: Message-ID: On Mon, 3 Nov 2025 19:12:43 GMT, Roger Riggs wrote: >> Hmm, obviously this is a judgement call and I'm curious what others think. >> >> My opinion is that I still think there should be a warning for shifts of -1. >> >> I mean, maybe to a _real_ hacker, then of course `foo << -1` makes perfect sense because it's just stating the "obvious" which is "shift the low order bit into the high order position and set all the other bits to zero", right?? :) >> >> I just don't think the average Java programmer automatically understands that. >> >> Yes, it's an idiom or "handy trick", but if hasn't attained the status of being universally recognized then it doesn't deserve a special exception. >> >> On the other hand, excluding -1 from the warning would be less disruptive (at least, to the real hackers out there), and that has its own merits. So I don't have a super strong opinion about it. > > This might be worth a corpus scan to see how common it is to shift by -1 or other constants, either int or long. > Someone, might interpret `v << -1` as a right shift, is it more likely to misinterpret it as using more than 5/6 bits of the shift or considering it signed. I am working on a corpus run, will take some days probably. But I am not sure if producing a warning for code that is "correct, but advanced use" is realistic. Maybe the line needs to be draw closer to "the code is probably buggy/highly suspicious". @rgiulietti - thanks, the explanation makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2495062625 From acobbs at openjdk.org Wed Nov 5 15:41:07 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 5 Nov 2025 15:41:07 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v3] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 15:26:31 GMT, Jan Lahoda wrote: > Maybe the line needs to be draw closer to "the code is probably buggy/highly suspicious". I'm OK with this more conservative approach, which should satisfy all the "real hackers": instead of warning for values outside of the range `[0,n)` (where `n` is 32 or 64), only warn for values outside of the range `(-n, n)`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2495106722 From mbaesken at openjdk.org Wed Nov 5 16:09:53 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Nov 2025 16:09:53 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 16:49:06 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Use lto configure flags in hs build Here are the lib sizes of libsplashscreen without / with lto for our toolchains at SAP (gcc 13.2.0, VS2022, Xcode 15.4) jdk opt / opt+LTO 1.5M / 1.5M aix_ppc64/images/jdk/lib/libsplashscreen.so 304K / 220K linux_aarch64/images/jdk/lib/libsplashscreen.so 292K / 180K linux_alpine_x86_64/images/jdk/lib/libsplashscreen.so 376K / 228K linux_ppc64le/images/jdk/lib/libsplashscreen.so 288K / 176K linux_x86_64/images/jdk/lib/libsplashscreen.so 388K / 240K darwinaarch64/images/jdk/lib/libsplashscreen.dylib 304K / 196K darwinintel64/images/jdk/lib/libsplashscreen.dylib 204K / 204K windows x86_64/images/jdk/bin/splashscreen.dll pdb / debuginfo size : jdk opt / opt+LTO 1.4M / 984K linux_aarch64/images/jdk/lib/libsplashscreen.debuginfo 1.4M / 924K linux_alpine_x86_64/images/jdk/lib/libsplashscreen.debuginfo 1.4M / 976K linux_ppc64le/images/jdk/lib/libsplashscreen.debuginfo 1.4M / 924K linux_x86_64/images/jdk/lib/libsplashscreen.debuginfo 352K / 344K windows x86_64/images/jdk/bin/splashscreen.dll.pdb ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3492076027 From mbaesken at openjdk.org Wed Nov 5 16:12:00 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 5 Nov 2025 16:12:00 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 13:37:11 GMT, Erik Joelsson wrote: > Yes, please only define the values once and use the variables in the JVM makefile. I adjusted the build flag settings in JvmFeatures.gmk to use the flags set by configure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3492084845 From erikj at openjdk.org Wed Nov 5 17:48:28 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 5 Nov 2025 17:48:28 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: Message-ID: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> On Tue, 4 Nov 2025 16:49:06 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Use lto configure flags in hs build make/autoconf/flags-cflags.m4 line 285: > 283: C_O_FLAG_NONE="-O0" > 284: > 285: # link time optimization can be additionally enabled on lib level I don't think this comment makes much sense in this context. make/common/native/Flags.gmk line 69: > 67: $1_OPT_CFLAGS += $(C_O_FLAG_LTO) > 68: $1_OPT_CXXFLAGS += $(CXX_O_FLAG_LTO) > 69: endif I don't think adding the LTO flags to the OPT flags is the right move, but if we are going with that, then this addition of LTO flags should only be done if `$$($1_OPTIMIZATION)` is set, as otherwise, those flags are already added through `$$($2_OPT_CFLAGS)`. That means, this block should be moved into the else block above, before the endif on line 64. However, the OPT flags are treated separately through SetupCompilerFlags and SetupCompileFileFlags because it should be possible to override the optimization level on a per file basis. The LTO flags on the other hand, are not possible to override on a per file basis, so we should not be tinkering with those in the SetupCompileFileFlags macro at all. So mixing in the LTO flags with the OPT flags is the wrong move. make/common/native/Flags.gmk line 242: > 240: ifeq ($$($1_LINK_TIME_OPTIMIZATION), true) > 241: $1_EXTRA_LDFLAGS += $(LDFLAGS_LTO) > 242: endif For flag ordering, I think this being a link unit global setting should be appended before the OS and TOOLCHAIN specific flags above. make/hotspot/lib/JvmFeatures.gmk line 186: > 184: else ifeq ($(call isCompiler, microsoft), true) > 185: JVM_CFLAGS_FEATURES += $(CXX_O_FLAG_LTO) > 186: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) Now that we have variables for LTO flags, we shouldn't need compiler type checks for adding them. We can keep the conditionals for the other flags, but adding LTO flags looks compiler agnostic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495462638 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495525800 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495534912 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2495546178 From henryjen at openjdk.org Wed Nov 5 17:47:38 2025 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 5 Nov 2025 17:47:38 GMT Subject: RFR: 8347831: Re-examine version check when cross linking Message-ID: This PR include build changes from @magicus and jlink change to verify the build signature. Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home ? java --version openjdk 26-internal 2026-03-17 OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) ? jlink --version 26-internal ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux ? jlink --add-modules java.base --output macos ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A ------------- Commit messages: - JLink to check java build information - Build changes to generate release.txt for java.base and jdk.jlink. Changes: https://git.openjdk.org/jdk/pull/28155/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347831 Stats: 96 lines in 8 files changed: 76 ins; 9 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From erikj at openjdk.org Wed Nov 5 18:10:01 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 5 Nov 2025 18:10:01 GMT Subject: RFR: 8347831: Re-examine version check when cross linking In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 17:41:44 GMT, Henry Jen wrote: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A I'm not thrilled about the code duplication between Gensrc.gmk in java.base and and jdk.jlink. I think this should be extracted out into a common file in some way. Having 2 copies of the template file also seems suboptimal. make/modules/java.base/Gensrc.gmk line 129: > 127: RELEASE_FILE_VARDEPS := $(COMPANY_NAME) $(VERSION_STRING) $(VERSION_DATE) > 128: RELEASE_FILE_VARDEPS_FILE := $(call DependOnVariable, RELEASE_FILE_VARDEPS, \ > 129: $(SUPPORT_OUTPUTDIR)/gensrc/$(MODULE)/jlink_release_txt.vardeps) Continuation indentation should be 4 spaces (see https://openjdk.org/groups/build/doc/code-conventions.html). make/modules/java.base/Gensrc.gmk line 134: > 132: SOURCE_FILES := $(RELEASE_FILE_TEMPLATE), \ > 133: OUTPUT_FILE := $(RELEASE_FILE_TARGET), \ > 134: REPLACEMENTS := \ Continuation indentation 4 spaces. make/modules/java.base/Gensrc.gmk line 140: > 138: )) > 139: > 140: $(OUTPUT_FILE): $(RELEASE_FILE_VARDEPS_FILE) There is no variable `OUTPUT_FILE` defined. I think this should be `$(BUILD_RELEASE_FILE)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3423620882 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2495596212 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2495596793 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2495599114 From aboldtch at openjdk.org Wed Nov 5 19:25:58 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 5 Nov 2025 19:25:58 GMT Subject: RFR: 8371346: ZGC: Flexible heap base selection Message-ID: ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base. Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties. With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM. This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base. I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits. The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that. On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. Performance testing show no significant differences. Testing: * GHA * Running ZGC tier1-8 on Oracle supported platforms ------------- Commit messages: - Initial Test Implementation - Initial implementation flexible heap base - Constrain ZAddressOffsetMax correctly when multi-partition fails - Log reserved size correctly when multi-partition fails - Cleanup headers - Consistent types zAddress Changes: https://git.openjdk.org/jdk/pull/28161/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371346 Stats: 1234 lines in 24 files changed: 907 ins; 290 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/28161.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28161/head:pull/28161 PR: https://git.openjdk.org/jdk/pull/28161 From mbaesken at openjdk.org Thu Nov 6 09:00:13 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 09:00:13 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> On Wed, 5 Nov 2025 17:45:56 GMT, Erik Joelsson wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Use lto configure flags in hs build > > make/hotspot/lib/JvmFeatures.gmk line 186: > >> 184: else ifeq ($(call isCompiler, microsoft), true) >> 185: JVM_CFLAGS_FEATURES += $(CXX_O_FLAG_LTO) >> 186: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) > > Now that we have variables for LTO flags, we shouldn't need compiler type checks for adding them. We can keep the conditionals for the other flags, but adding LTO flags looks compiler agnostic. We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2498082307 From jwaters at openjdk.org Thu Nov 6 09:12:03 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 6 Nov 2025 09:12:03 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> Message-ID: On Thu, 6 Nov 2025 08:57:27 GMT, Matthias Baesken wrote: >> make/hotspot/lib/JvmFeatures.gmk line 186: >> >>> 184: else ifeq ($(call isCompiler, microsoft), true) >>> 185: JVM_CFLAGS_FEATURES += $(CXX_O_FLAG_LTO) >>> 186: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) >> >> Now that we have variables for LTO flags, we shouldn't need compiler type checks for adding them. We can keep the conditionals for the other flags, but adding LTO flags looks compiler agnostic. > > We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. That's due to how the toolchains work, with VC you're passing the options directly to the linker, while for gcc/clang you're passing the optimization flag to the driver, which understands the optimization option, unlike link.exe (Technically you're passing it to the compiler for gcc/clang I believe, both of them use the compiler's middle end to optimize your code during the link step when LTO is enabled from what I recall) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2498129638 From alanb at openjdk.org Thu Nov 6 11:10:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 6 Nov 2025 11:10:09 GMT Subject: RFR: 8347831: Re-examine version check when cross linking In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 17:41:44 GMT, Henry Jen wrote: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A I'm puzzling as to why the resource has to be saved in the jdk.jlink module. When cross linking, jlink should only need to check the company/version of java.base in the current image vs. company/version of the java.base found on the module path. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28155#issuecomment-3496614334 From eosterlund at openjdk.org Thu Nov 6 11:38:35 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 6 Nov 2025 11:38:35 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v15] In-Reply-To: References: Message-ID: > This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. > > The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. > > This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. > > The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. > > The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. > > Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. > Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in... Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Comment update - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - remove include - Interned string value word accounting - Dont load all objects when JVMTI CFLH is on - Remove duplicate string dedup disabling when dumping - Accept interned strings sharing value with another string - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - ... and 21 more: https://git.openjdk.org/jdk/compare/b0536f9c...afdb11ee ------------- Changes: https://git.openjdk.org/jdk/pull/27732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=14 Stats: 8721 lines in 106 files changed: 5943 ins; 2318 del; 460 mod Patch: https://git.openjdk.org/jdk/pull/27732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732 PR: https://git.openjdk.org/jdk/pull/27732 From mbaesken at openjdk.org Thu Nov 6 12:30:47 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 12:30:47 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v6] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Remove lto related comment in flags-cflags.m4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/72ba9ed1..75f83437 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From mbaesken at openjdk.org Thu Nov 6 12:35:05 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 12:35:05 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: On Wed, 5 Nov 2025 17:38:58 GMT, Erik Joelsson wrote: > I don't think adding the LTO flags to the OPT flags is the right move So where should I move it? After all it is link time *optimization* so it is an optimization related tool feature. But should I remove it completely from SetupCompileFileFlags because having it in SetupCompilerFlags is sufficient for out task ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2498787207 From mbaesken at openjdk.org Thu Nov 6 12:49:22 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 12:49:22 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v7] In-Reply-To: References: Message-ID: <5oAFgVlLJT7GeJB0w5ufEgOlGoO8mLYo2qjxkHGm_Hc=.7c5bdf18-b9a5-4a54-afd8-8059a45a22b9@github.com> > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Move LTO link flag settings a little up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/75f83437..e68bc711 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=05-06 Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From eosterlund at openjdk.org Thu Nov 6 13:33:04 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 6 Nov 2025 13:33:04 GMT Subject: RFR: 8371346: ZGC: Flexible heap base selection In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 19:19:23 GMT, Axel Boldt-Christmas wrote: > ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base. > > Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties. > > With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM. > > This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base. > > I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits. > > The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that. > > On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. > > There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. > > Performance testing show no significant differences. > > Testing: > * GHA > * Running ZGC tier1-8 on Oracle supported platforms Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28161#pullrequestreview-3428202976 From mbaesken at openjdk.org Thu Nov 6 13:52:23 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 13:52:23 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v8] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Simplify lto flag assignment for hs in JvmFeatures.gmk ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/e68bc711..a5e266e0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=06-07 Stats: 10 lines in 1 file changed: 2 ins; 6 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From erikj at openjdk.org Thu Nov 6 13:52:24 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 6 Nov 2025 13:52:24 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> <2xxNnTYM_sGTOtbEafbA6GDVO1Qy2WOs2midOMhBMIs=.4e1c8ee1-c75f-4d41-8e19-75987fca5b92@github.com> Message-ID: On Thu, 6 Nov 2025 09:09:52 GMT, Julian Waters wrote: >> We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. > > That's due to how the toolchains work, with VC you're passing the options directly to the linker, while for gcc/clang you're passing the optimization flag to the driver, which understands the optimization option, unlike link.exe (Technically you're passing it to the compiler for gcc/clang I believe, both of them use the compiler's middle end to optimize your code during the link step when LTO is enabled from what I recall) > We still add CXX_O_FLAG_HIGHEST_JVM to the JVM_LDFLAGS_FEATURES for gcc/clang , but not for msvc. Not sure why. So there is still a bit of difference between compilers. That is what I meant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2499024967 From erikj at openjdk.org Thu Nov 6 14:01:54 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 6 Nov 2025 14:01:54 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: On Thu, 6 Nov 2025 12:32:14 GMT, Matthias Baesken wrote: >> make/common/native/Flags.gmk line 69: >> >>> 67: $1_OPT_CFLAGS += $(C_O_FLAG_LTO) >>> 68: $1_OPT_CXXFLAGS += $(CXX_O_FLAG_LTO) >>> 69: endif >> >> I don't think adding the LTO flags to the OPT flags is the right move, but if we are going with that, then this addition of LTO flags should only be done if `$$($1_OPTIMIZATION)` is set, as otherwise, those flags are already added through `$$($2_OPT_CFLAGS)`. That means, this block should be moved into the else block above, before the endif on line 64. >> >> However, the OPT flags are treated separately through SetupCompilerFlags and SetupCompileFileFlags because it should be possible to override the optimization level on a per file basis. The LTO flags on the other hand, are not possible to override on a per file basis, so we should not be tinkering with those in the SetupCompileFileFlags macro at all. So mixing in the LTO flags with the OPT flags is the wrong move. > >> I don't think adding the LTO flags to the OPT flags is the right move > > So where should I move it? After all it is link time *optimization* so it is an optimization related tool feature. > But should I remove it completely from SetupCompileFileFlags because having it in SetupCompilerFlags is sufficient for out task ? Again, the optimization flags aren't handled as a separate set of variables because they are of the category "optimization". It's because optimization flags are handled on a higher level with an abstraction of "low", "medium", "high" etc, and that abstraction allows for specific file overrides. That's what the `*_OPT_C*FLAGS` are there to handle. Since the LTO flags are not related to this abstraction, they should not be mixed into these variables, that is just confusing and adding unnecessary complexity. The LTO flags should just be stacked on to the `$1_EXTRA_*` flags like any other. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2499047995 From erikj at openjdk.org Thu Nov 6 14:01:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 6 Nov 2025 14:01:59 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v8] In-Reply-To: References: Message-ID: On Thu, 6 Nov 2025 13:52:23 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Simplify lto flag assignment for hs in JvmFeatures.gmk make/hotspot/lib/JvmFeatures.gmk line 182: > 180: JVM_LDFLAGS_FEATURES += $(LDFLAGS_LTO) > 181: else > 182: JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) That's better, but looking at this again, if we are now abstracting LTO support into `SetupNativeCompilation`, then CompileJvm.gmk/JvmFeatures.gmk should use that instead of adding the flags manually. What I mean is, in this conditional on the jvm feature `link-time-opt`, a variable should be set that causes `LINK_TIME_OPTIMIZATION` to be set to true for libjvm. No LTO flags should be explicitly added here, just the optimization flag for gcc/clang. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2499068717 From mbaesken at openjdk.org Thu Nov 6 15:30:30 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 6 Nov 2025 15:30:30 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v9] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Use LINK_TIME_OPTIMIZATION for libjvm build too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/a5e266e0..bea8d07a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=07-08 Stats: 7 lines in 2 files changed: 2 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From acobbs at openjdk.org Thu Nov 6 21:03:02 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Nov 2025 21:03:02 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v4] In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 15:37:54 GMT, Archie Cobbs wrote: > > Maybe the line needs to be draw closer to "the code is probably buggy/highly suspicious". > > I'm OK with this more conservative approach, which should satisfy all the "real hackers": instead of warning for values outside of the range `[0,n)` (where `n` is 32 or 64), only warn for values outside of the range `(-n, n)`. I went ahead and updated this PR and the CSR to not warn about negative shifts that are otherwise in range. Please take a look at both and let me know what you guys think. We can always turn the screws harder in the future if appropriate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27102#discussion_r2500850339 From acobbs at openjdk.org Thu Nov 6 21:03:01 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Thu, 6 Nov 2025 21:03:01 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v4] In-Reply-To: References: Message-ID: <7G0o3Ph7D9I11xzojJwIXuJ4nHvNtXtQpy2BdfuZ6Kw=.b1766068-44ad-4a74-ac51-b37b191c3e65@github.com> > When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. > > This can create a trap for the unwary, as in this example: > > public long readLongBigEndian(byte[] buf, int offset) { > return ((buf[offset + 0] & 0xff) << 56) // BUG HERE > | ((buf[offset + 1] & 0xff) << 48) // BUG HERE > | ((buf[offset + 2] & 0xff) << 40) // BUG HERE > | ((buf[offset + 3] & 0xff) << 32) // BUG HERE > | ((buf[offset + 4] & 0xff) << 24) > | ((buf[offset + 5] & 0xff) << 16) > | ((buf[offset + 6] & 0xff) << 8) > | ((buf[offset + 7] & 0xff); > } > > This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[0...31]` or a `long` bit shift not in the range `[0...63]`. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Don't warn for negative shift values that are otherwise in range. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27102/files - new: https://git.openjdk.org/jdk/pull/27102/files/89fe2fb1..4156e813 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=02-03 Stats: 69 lines in 6 files changed: 13 ins; 5 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/27102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102 PR: https://git.openjdk.org/jdk/pull/27102 From henryjen at openjdk.org Fri Nov 7 00:46:44 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 7 Nov 2025 00:46:44 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Use release.txt from java.base module in current and target for comparison ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/c311f098..7df6e157 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=00-01 Stats: 74 lines in 5 files changed: 14 ins; 35 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From eosterlund at openjdk.org Fri Nov 7 10:11:08 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Nov 2025 10:11:08 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v16] In-Reply-To: References: Message-ID: > This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. > > The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. > > This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. > > The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. > > The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. > > Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. > Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in... Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Comment update - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - remove include - Interned string value word accounting - Dont load all objects when JVMTI CFLH is on - Remove duplicate string dedup disabling when dumping - Accept interned strings sharing value with another string - ... and 22 more: https://git.openjdk.org/jdk/compare/e34a8318...7e3dee89 ------------- Changes: https://git.openjdk.org/jdk/pull/27732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=15 Stats: 8722 lines in 106 files changed: 5941 ins; 2318 del; 463 mod Patch: https://git.openjdk.org/jdk/pull/27732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732 PR: https://git.openjdk.org/jdk/pull/27732 From alanb at openjdk.org Fri Nov 7 10:25:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Nov 2025 10:25:05 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: <77TzIw84nfa3sIqFqINBceemnxhJ3RkCdjaqy6yKbSk=.e3d844d9-68ae-4302-b344-6c686c54b169@github.com> On Fri, 7 Nov 2025 00:46:44 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Use release.txt from java.base module in current and target for comparison src/java.base/share/classes/jdk/internal/jmod/resources/release.txt.template line 1: > 1: @@COMPANY_NAME@@-@@VERSION_STRING@@-@@VERSION_DATE@@ jdk.internal.jmod is for the code to access JMOD files. I think we'll need to find a better location for release.txt Putting in the top-level directory of java.base would create an attractive nuisance so jdk.internal.* is better. Maybe put it in misc for now until we find somewhere better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502620339 From alanb at openjdk.org Fri Nov 7 11:05:07 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 7 Nov 2025 11:05:07 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 00:46:44 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Use release.txt from java.base module in current and target for comparison The updated version is much simpler, thank you. Just a few small comments on the jlink changes. > This PR include build changes from @magicus and jlink change to verify the build signature. In that case, you'll need to list Magnus (`/contributor` command). src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 245: > 243: public static final String OPTIONS_RESOURCE = "jdk/tools/jlink/internal/options"; > 244: // Release information as in the java.base module for target image > 245: public static final String JDK_RELEASE_RESOURCE = "jdk/internal/jmod/resources/release.txt"; I assume this can be private. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 256: > 254: } > 255: > 256: try (var r = new BufferedReader(new InputStreamReader(in.get()))) { It's not immediately obvious that `in` is an `Optional` , so maybe rename and/or avoid var for this case. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 600: > 598: ModuleReference target = finder.find("java.base").get(); > 599: String currentRelease = getReleaseInfo(current).orElseThrow(() -> > 600: new IllegalArgumentException("Cannot find release.txt")); I assume this is an err.jlink.version.mismatch case too. The packaged version of java.base on the module path is missing the resource file so it must be an older version, hence a mismatch. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 603: > 601: String targetRelease = getReleaseInfo(target).orElse("N/A"); > 602: if (! currentRelease.equals(targetRelease)) { > 603: // jlink version and java.base version do not match. The comment could be clearer. It's a version mismatch between the current runtime and the target runtime image. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 610: > 608: } > 609: } catch (NoSuchElementException e) { > 610: assert false : "Should have found java.base module"; I think you can drop the catching of NoSuchElementException, jlink should just fail if this were to happen. ------------- PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3432931919 PR Comment: https://git.openjdk.org/jdk/pull/28155#issuecomment-3501891672 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502816169 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502693905 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502804031 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502808353 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2502682900 From aboldtch at openjdk.org Fri Nov 7 11:10:10 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 7 Nov 2025 11:10:10 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v16] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 10:11:08 GMT, Erik ?sterlund wrote: >> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. >> >> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. >> >> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. >> >> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. >> >> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. >> >> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. >> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or... > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits: > > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - Comment update > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - remove include > - Interned string value word accounting > - Dont load all objects when JVMTI CFLH is on > - Remove duplicate string dedup disabling when dumping > - Accept interned strings sharing value with another string > - ... and 22 more: https://git.openjdk.org/jdk/compare/e34a8318...7e3dee89 Final merges looks good. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3433114312 From eosterlund at openjdk.org Fri Nov 7 12:57:49 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Nov 2025 12:57:49 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v17] In-Reply-To: References: Message-ID: > This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. > > The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. > > This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. > > The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. > > The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. > > Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. > Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in... Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Fix test group anomaly - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Comment update - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - Merge branch 'master' into 8326035_JEP_object_streaming_v6 - remove include - Interned string value word accounting - Dont load all objects when JVMTI CFLH is on - ... and 24 more: https://git.openjdk.org/jdk/compare/167c952b...754006b5 ------------- Changes: https://git.openjdk.org/jdk/pull/27732/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=16 Stats: 8724 lines in 107 files changed: 5942 ins; 2318 del; 464 mod Patch: https://git.openjdk.org/jdk/pull/27732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732 PR: https://git.openjdk.org/jdk/pull/27732 From aboldtch at openjdk.org Fri Nov 7 12:57:49 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 7 Nov 2025 12:57:49 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v17] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 12:54:27 GMT, Erik ?sterlund wrote: >> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. >> >> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. >> >> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. >> >> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. >> >> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. >> >> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. >> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or... > > Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: > > - Fix test group anomaly > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - Comment update > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - Merge branch 'master' into 8326035_JEP_object_streaming_v6 > - remove include > - Interned string value word accounting > - Dont load all objects when JVMTI CFLH is on > - ... and 24 more: https://git.openjdk.org/jdk/compare/167c952b...754006b5 Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3433727151 From krk at openjdk.org Fri Nov 7 13:44:17 2025 From: krk at openjdk.org (Kerem Kat) Date: Fri, 7 Nov 2025 13:44:17 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders Message-ID: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. image ------------- Commit messages: - 8371425: Include folder names in vscode workspace virtual folders Changes: https://git.openjdk.org/jdk/pull/28194/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28194&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371425 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28194/head:pull/28194 PR: https://git.openjdk.org/jdk/pull/28194 From erikj at openjdk.org Fri Nov 7 13:52:01 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 7 Nov 2025 13:52:01 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 00:46:44 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Use release.txt from java.base module in current and target for comparison Build changes look good now, pending Alan's comment about location of the output file. ------------- PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3434055982 From erikj at openjdk.org Fri Nov 7 13:57:03 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 7 Nov 2025 13:57:03 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders In-Reply-To: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> Message-ID: On Fri, 7 Nov 2025 13:37:57 GMT, Kerem Kat wrote: > Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. > > image I think this change makes sense, but it would be good to get input from other VS Code users. make/ide/vscode/hotspot/CreateVSCodeProject.gmk line 88: > 86: $(call RelativePath,$(OUTPUTDIR),$(TOPDIR)))))!g' \ > 87: -e 's!{{TOPDIR_BASE}}!$(notdir $(TOPDIR))!g' \ > 88: -e 's!{{OUTPUT_BASE}}!$(notdir $(OUTPUTDIR))!g' \ These lines aren't lining up with the rest. Please see https://openjdk.org/groups/build/doc/code-conventions.html for details on build system code conventions. ------------- PR Review: https://git.openjdk.org/jdk/pull/28194#pullrequestreview-3434077079 PR Review Comment: https://git.openjdk.org/jdk/pull/28194#discussion_r2503668068 From krk at openjdk.org Fri Nov 7 14:08:34 2025 From: krk at openjdk.org (Kerem Kat) Date: Fri, 7 Nov 2025 14:08:34 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders [v2] In-Reply-To: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> Message-ID: <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> > Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. > > image Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: fix space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28194/files - new: https://git.openjdk.org/jdk/pull/28194/files/f0145f45..9f39f939 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28194&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28194&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28194/head:pull/28194 PR: https://git.openjdk.org/jdk/pull/28194 From erikj at openjdk.org Fri Nov 7 14:15:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 7 Nov 2025 14:15:08 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders [v2] In-Reply-To: <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> Message-ID: On Fri, 7 Nov 2025 14:08:34 GMT, Kerem Kat wrote: >> Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. >> >> image > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > fix space ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28194#pullrequestreview-3434194031 From eosterlund at openjdk.org Fri Nov 7 14:50:52 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Nov 2025 14:50:52 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v18] In-Reply-To: References: Message-ID: > This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. > > The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. > > This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. > > The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. > > The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. > > Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. > Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in... Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: Remove -server in test for static GHA build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27732/files - new: https://git.openjdk.org/jdk/pull/27732/files/754006b5..84d79301 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=16-17 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27732.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732 PR: https://git.openjdk.org/jdk/pull/27732 From aboldtch at openjdk.org Fri Nov 7 14:50:53 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 7 Nov 2025 14:50:53 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v18] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 14:47:07 GMT, Erik ?sterlund wrote: >> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. >> >> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. >> >> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. >> >> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. >> >> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. >> >> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. >> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or... > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Remove -server in test for static GHA build Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27732#pullrequestreview-3434398193 From mbaesken at openjdk.org Fri Nov 7 15:06:51 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 7 Nov 2025 15:06:51 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: > We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. > But for other JDK native libs, we do not have support for this feature. > LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Add lto to EXTRA_FLAGS, not to OPT ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27976/files - new: https://git.openjdk.org/jdk/pull/27976/files/bea8d07a..bc591fdf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27976&range=08-09 Stats: 15 lines in 1 file changed: 5 ins; 10 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27976.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27976/head:pull/27976 PR: https://git.openjdk.org/jdk/pull/27976 From mbaesken at openjdk.org Fri Nov 7 15:06:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 7 Nov 2025 15:06:52 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v5] In-Reply-To: References: <31uD61UWj2KbHHXtP8wsSHHbAAraD1MRQPpVrxKse8Q=.1037cea5-a914-46fd-b481-1cc72bbef719@github.com> Message-ID: On Thu, 6 Nov 2025 13:53:07 GMT, Erik Joelsson wrote: >>> I don't think adding the LTO flags to the OPT flags is the right move >> >> So where should I move it? After all it is link time *optimization* so it is an optimization related tool feature. >> But should I remove it completely from SetupCompileFileFlags because having it in SetupCompilerFlags is sufficient for out task ? > > Again, the optimization flags aren't handled as a separate set of variables because they are of the category "optimization". It's because optimization flags are handled on a higher level with an abstraction of "low", "medium", "high" etc, and that abstraction allows for specific file overrides. That's what the `*_OPT_C*FLAGS` are there to handle. Since the LTO flags are not related to this abstraction, they should not be mixed into these variables, that is just confusing and adding unnecessary complexity. > > The LTO flags should just be stacked on to the `$1_EXTRA_*` flags like any other. I adjusted my changes to Flags.gmk . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2504024684 From eosterlund at openjdk.org Fri Nov 7 15:28:46 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Nov 2025 15:28:46 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v18] In-Reply-To: References: Message-ID: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com> On Fri, 7 Nov 2025 14:50:52 GMT, Erik ?sterlund wrote: >> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. >> >> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. >> >> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. >> >> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. >> >> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. >> >> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. >> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or... > > Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: > > Remove -server in test for static GHA build Thank you for the reviews everyone! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3503184650 From eosterlund at openjdk.org Fri Nov 7 15:32:03 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 7 Nov 2025 15:32:03 GMT Subject: Integrated: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 15:18:16 GMT, Erik ?sterlund wrote: > This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC. > > The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward. > > This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism. > > The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects. > > The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread. > > Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible. > Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in... This pull request has now been integrated. Changeset: c8656449 Author: Erik ?sterlund URL: https://git.openjdk.org/jdk/commit/c8656449c28581ae9c3d815105e338e42253bb43 Stats: 8726 lines in 108 files changed: 5942 ins; 2318 del; 466 mod 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC Co-authored-by: Axel Boldt-Christmas Co-authored-by: Joel Sikstr?m Co-authored-by: Stefan Karlsson Reviewed-by: aboldtch, iklam, kvn ------------- PR: https://git.openjdk.org/jdk/pull/27732 From henryjen at openjdk.org Fri Nov 7 16:46:04 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 7 Nov 2025 16:46:04 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 10:57:54 GMT, Alan Bateman wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Use release.txt from java.base module in current and target for comparison > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 600: > >> 598: ModuleReference target = finder.find("java.base").get(); >> 599: String currentRelease = getReleaseInfo(current).orElseThrow(() -> >> 600: new IllegalArgumentException("Cannot find release.txt")); > > I assume this is an err.jlink.version.mismatch case too. The packaged version of java.base on the module path is missing the resource file so it must be an older version, hence a mismatch. This is for the current runtime of jlink, so this should never happen? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2504531025 From henryjen at openjdk.org Fri Nov 7 18:53:42 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 7 Nov 2025 18:53:42 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v3] In-Reply-To: References: Message-ID: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Address review feedbacks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/7df6e157..8df7e809 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=01-02 Stats: 21 lines in 3 files changed: 3 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From rriggs at openjdk.org Fri Nov 7 20:35:05 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Nov 2025 20:35:05 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Thu, 30 Oct 2025 02:59:45 GMT, Xueming Shen wrote: >> ### Summary >> >> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. >> >> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: >> >> **String.equalsIgnoreCase(String)** >> >> - Unicode-aware, locale-independent. >> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. >> - Limited: does not support 1:M mapping defined in Unicode case folding. >> >> **Character.toLowerCase(int) / Character.toUpperCase(int)** >> >> - Locale-independent, single code point only. >> - No support for 1:M mappings. >> >> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** >> >> - Based on Unicode SpecialCasing.txt, supports 1:M mappings. >> - Intended primarily for presentation/display, not structural case-insensitive matching. >> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. >> >> **1:M mapping example, U+00DF (?)** >> >> - String.toUpperCase(Locale.ROOT, "?") ? "SS" >> - Case folding produces "ss", matching Unicode caseless comparison rules. >> >> >> jshell> "\u00df".equalsIgnoreCase("ss") >> $22 ==> false >> >> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") >> $24 ==> true >> >> >> ### Motivation & Direction >> >> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. >> >> - Unicode-compliant **full** case folding. >> - Simpler, stable and more efficient case-less matching without workarounds. >> - Brings Java's string comparison handling in line with other programming languages/libraries. >> >> This PR proposes to introduce the following comparison methods in `String` class >> >> - boolean equalsFoldCase(String anotherString) >> - int compareToFoldCase(String anotherString) >> - Comparator UNICODE_CASEFOLD_ORDER >> >> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. >> >> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. >> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > update to use value long for folding src/java.base/share/classes/java/lang/StringLatin1.java line 278: > 276: return 1; > 277: } > 278: if (k2 < olast || f1 != 0) { Should `f1` here be `f2`, partial codePoint remaining in 2nd string? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505385527 From rriggs at openjdk.org Fri Nov 7 20:35:05 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Nov 2025 20:35:05 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Fri, 7 Nov 2025 20:30:53 GMT, Roger Riggs wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use value long for folding > > src/java.base/share/classes/java/lang/StringLatin1.java line 278: > >> 276: return 1; >> 277: } >> 278: if (k2 < olast || f1 != 0) { > > Should `f1` here be `f2`, partial codePoint remaining in 2nd string? A new test case maybe useful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505389674 From rriggs at openjdk.org Fri Nov 7 22:36:11 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 7 Nov 2025 22:36:11 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Thu, 30 Oct 2025 02:59:45 GMT, Xueming Shen wrote: >> ### Summary >> >> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. >> >> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: >> >> **String.equalsIgnoreCase(String)** >> >> - Unicode-aware, locale-independent. >> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. >> - Limited: does not support 1:M mapping defined in Unicode case folding. >> >> **Character.toLowerCase(int) / Character.toUpperCase(int)** >> >> - Locale-independent, single code point only. >> - No support for 1:M mappings. >> >> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** >> >> - Based on Unicode SpecialCasing.txt, supports 1:M mappings. >> - Intended primarily for presentation/display, not structural case-insensitive matching. >> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. >> >> **1:M mapping example, U+00DF (?)** >> >> - String.toUpperCase(Locale.ROOT, "?") ? "SS" >> - Case folding produces "ss", matching Unicode caseless comparison rules. >> >> >> jshell> "\u00df".equalsIgnoreCase("ss") >> $22 ==> false >> >> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") >> $24 ==> true >> >> >> ### Motivation & Direction >> >> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. >> >> - Unicode-compliant **full** case folding. >> - Simpler, stable and more efficient case-less matching without workarounds. >> - Brings Java's string comparison handling in line with other programming languages/libraries. >> >> This PR proposes to introduce the following comparison methods in `String` class >> >> - boolean equalsFoldCase(String anotherString) >> - int compareToFoldCase(String anotherString) >> - Comparator UNICODE_CASEFOLD_ORDER >> >> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. >> >> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. >> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > update to use value long for folding Looking good. I'll look at the javadoc again when the CSR comments are addressed. src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 53: > 51: public static boolean isDefined(int cp) { > 52: return getDefined(cp) != -1; > 53: } Extra space. src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 107: > 105: * family may appears independently or within a class. > 106: *

> 107: * For loose/case-insensitive matching, the back-refs, slices and singles apply {code toUpperCase} and Missing at-sign in markup: Suggestion: * For loose/case-insensitive matching, the back-refs, slices and singles apply {@code toUpperCase} and src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 136: > 134: * > 135: *

> 136: * @spec https://www.unicode.org/reports/tr18/#Simple_Loose_Matches I'd put @spec after @return. src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 152: > 150: } > 151: } > 152: } If expanded_case_cps was sorted, Array.binarySearch could be used to find the index of the first character in the range. And the loop could break when cp reaches the end of the range. src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 163: > 161: .stream() > 162: .mapToInt(Integer::intValue) > 163: .toArray(); It might be worthwhile to sort these to enable skipping a quicker break when the last one in the range is seen. src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 169: > 167: private static final int HASH_NEXT = 2; > 168: > 169: private static int[][] hashKeys(int[] keys) { It may be worthwhile to round up the hash modulo to a prime number to avoid unfortunate hash collisions. test/jdk/java/lang/String/UnicodeCaseFoldingTest.java line 31: > 29: * @compile --add-exports java.base/jdk.internal.lang=ALL-UNNAMED > 30: * UnicodeCaseFoldingTest.java > 31: * @run junit/othervm --add-exports java.base/jdk.internal.lang=ALL-UNNAMED The @module directive can replace the explicit --add-exports and the explicit @compile may be unnecessary. * @modules java.base/jdk.internal.lang:+open ------------- PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3436511645 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505610221 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505623056 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505629880 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505705459 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505699712 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505714395 PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2505728277 From serb at openjdk.org Sat Nov 8 00:37:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 8 Nov 2025 00:37:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT make/modules/java.desktop/lib/ClientLibraries.gmk line 229: > 227: EXCLUDES := $(LIBSPLASHSCREEN_EXCLUDES), \ > 228: OPTIMIZATION := SIZE, \ > 229: LINK_TIME_OPTIMIZATION := true, \ You do not need to change it in this patch, it can be done separately per lib. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2505913339 From jvernee at openjdk.org Sat Nov 8 01:26:02 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 8 Nov 2025 01:26:02 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders [v2] In-Reply-To: <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> Message-ID: On Fri, 7 Nov 2025 14:08:34 GMT, Kerem Kat wrote: >> Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. >> >> image > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > fix space Marked as reviewed by jvernee (Reviewer). As a VS Code user I welcome this change. The current folder names are fairly nondescript. ------------- PR Review: https://git.openjdk.org/jdk/pull/28194#pullrequestreview-3437007688 PR Comment: https://git.openjdk.org/jdk/pull/28194#issuecomment-3505550126 From dlsmith at openjdk.org Sat Nov 8 01:35:35 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Sat, 8 Nov 2025 01:35:35 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir Message-ID: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. ------------- Commit messages: - 8370154: Update @jls and @jvms taglets to point to local specs dir Changes: https://git.openjdk.org/jdk/pull/28207/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28207&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370154 Stats: 59 lines in 2 files changed: 38 ins; 14 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28207/head:pull/28207 PR: https://git.openjdk.org/jdk/pull/28207 From liach at openjdk.org Sat Nov 8 03:29:00 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 8 Nov 2025 03:29:00 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith wrote: > Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. > > I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. > > Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. Looks goood. Meanwhile, do you think we should retain external link support via a system property? For the Java SE API specification only distribution for JCP, we might want to link to a static link instead of a local relative link. (I think as long as we can link, a relative link like here is better because it will be stable in the specdiff for JCP review, avoiding spams) Since we removed the system property jspec.version, we should be able to remove this from the build files too: https://github.com/openjdk/jdk/blob/066810c877b206a66cc87537487b17f0481646c3/make/Docs.gmk#L295 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3505717390 From dlsmith at openjdk.org Sat Nov 8 04:32:59 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Sat, 8 Nov 2025 04:32:59 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith wrote: > Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. > > I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. > > Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. JCP reviews actually happen before GA, so I think the external links are always dead anyway? If it's something the JCP folks care about, I think the right solution is to include JLS & JVMS in the SE-only docs. (They are, after all, specs for Java SE.) But for now, I think the business as usual process is fine. I'll confirm there are no more uses of `jspec.version` and update Docs.gmk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3505881120 PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3505884846 From liach at openjdk.org Sat Nov 8 05:46:59 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 8 Nov 2025 05:46:59 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith wrote: > Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. > > I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. > > Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. I think we can go ahead with this once we verify Oracle's doc build passes. I will approve once the system property passing in Docs.gmk is updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3506017879 From alanb at openjdk.org Sat Nov 8 07:13:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 8 Nov 2025 07:13:03 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 16:43:48 GMT, Henry Jen wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 600: >> >>> 598: ModuleReference target = finder.find("java.base").get(); >>> 599: String currentRelease = getReleaseInfo(current).orElseThrow(() -> >>> 600: new IllegalArgumentException("Cannot find release.txt")); >> >> I assume this is an err.jlink.version.mismatch case too. The packaged version of java.base on the module path is missing the resource file so it must be an older version, hence a mismatch. > > This is for the current runtime of jlink, so this should never happen? That's right. If getReleaseInfo(current) were to fail then it suggests a JDK build or other bug. For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly? If java.base is found on the module path but it doesn't contain the release file then the updated code to use "N/A" is okay as it feeds into the error message that jlink will print. So I think the changes are nearly there. I've added the "csr" label to the PR as this change will need a CSR. There may be cases today that are cross linking successfully (they got lucky) but they will fail with the change due to the stricter check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2506343704 From liach at openjdk.org Sat Nov 8 22:05:00 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 8 Nov 2025 22:05:00 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith wrote: > Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. > > I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. > > Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. Verified this passes on Oracle's CI. I tested this patch on my local Linux-targeting OpenJDK WSL (because only Linux is building docs); the JVMS links become dead links in OpenJDK builds, which don't have access to JLS/JVMS, which are proprietary to Oracle. We should probably leave a comment that the dead links are intentional. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28207#pullrequestreview-3438821864 PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3506995226 From mbaesken at openjdk.org Mon Nov 10 08:09:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 10 Nov 2025 08:09:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Sat, 8 Nov 2025 00:34:02 GMT, Sergey Bylokhov wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Add lto to EXTRA_FLAGS, not to OPT > > make/modules/java.desktop/lib/ClientLibraries.gmk line 229: > >> 227: EXCLUDES := $(LIBSPLASHSCREEN_EXCLUDES), \ >> 228: OPTIMIZATION := SIZE, \ >> 229: LINK_TIME_OPTIMIZATION := true, \ > > You do not need to change it in this patch, it can be done separately per lib. I think there was the concern raised previously, that without setting it for at least one lib, nobody would use/try it and the feature would 'rot' . (there was also the idea to add a configure option to enable/disable the whole 'lto on jdk native libs' ; I can add this but currently not sure if this is desired) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2509194261 From krk at openjdk.org Mon Nov 10 11:02:03 2025 From: krk at openjdk.org (Kerem Kat) Date: Mon, 10 Nov 2025 11:02:03 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders [v2] In-Reply-To: <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> Message-ID: On Fri, 7 Nov 2025 14:08:34 GMT, Kerem Kat wrote: >> Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. >> >> image > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > fix space Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28194#issuecomment-3510867247 From duke at openjdk.org Mon Nov 10 11:02:03 2025 From: duke at openjdk.org (duke) Date: Mon, 10 Nov 2025 11:02:03 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders [v2] In-Reply-To: <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> Message-ID: On Fri, 7 Nov 2025 14:08:34 GMT, Kerem Kat wrote: >> Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. >> >> image > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > fix space @krk Your change (at version 9f39f939e45a33e1f575e046e551e4060bdde109) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28194#issuecomment-3510871279 From shade at openjdk.org Mon Nov 10 11:36:40 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 10 Nov 2025 11:36:40 GMT Subject: RFR: 8371425: Include folder names in vscode workspace virtual folders [v2] In-Reply-To: <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> <0fa5D6sGt9QbOw-lXmpakkb6tLzVKMIhKpnBeyMO570=.e3d229be-6f19-42db-bf1c-cd8821731d84@github.com> Message-ID: On Fri, 7 Nov 2025 14:08:34 GMT, Kerem Kat wrote: >> Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. >> >> image > > Kerem Kat has updated the pull request incrementally with one additional commit since the last revision: > > fix space Looks reasonable, thanks. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28194#pullrequestreview-3442667229 From krk at openjdk.org Mon Nov 10 11:36:41 2025 From: krk at openjdk.org (Kerem Kat) Date: Mon, 10 Nov 2025 11:36:41 GMT Subject: Integrated: 8371425: Include folder names in vscode workspace virtual folders In-Reply-To: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> References: <0sJzgar4e3ohyX0lw-p9nNB0OIbLhuZ9j38VEHwWaio=.d9237d8c-4df1-460a-90f8-4bceeda14a3c@github.com> Message-ID: <6PlIW4NUW_IoFIpHbkJZzLvxvZABA4s5_AY_ZtQVozg=.a1ce23c0-c16d-497e-b6e4-60d28a211bfd@github.com> On Fri, 7 Nov 2025 13:37:57 GMT, Kerem Kat wrote: > Include top-level folder name in the source root, to help distinguishing different vscode instances and include the build configuration name in the "Build artifacts" virtual folder name in vscode, in the generated workspace file from `make vscode-project`. > > image This pull request has now been integrated. Changeset: 98f40e45 Author: Kerem Kat Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/98f40e4575538d91f509c85d9d657a8973f464be Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod 8371425: Include folder names in vscode workspace virtual folders Reviewed-by: erikj, jvernee, shade ------------- PR: https://git.openjdk.org/jdk/pull/28194 From nbenalla at openjdk.org Mon Nov 10 16:15:38 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 10 Nov 2025 16:15:38 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v4] In-Reply-To: References: Message-ID: <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com> > Get JDK 27 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Updates due to the generate-symbol-data.sh location changing in 8367259 - Updates due to the generate-symbol-data.sh location changing in 8367259 - Merge branch 'master' into start-of-release-27 - update links to JVMS 26 and 27 - add missing enum - initial commit start-of-JDK-27 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/b51f2324..0652d5d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=02-03 Stats: 164507 lines in 1034 files changed: 112814 ins; 23251 del; 28442 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From henryjen at openjdk.org Mon Nov 10 16:35:13 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 10 Nov 2025 16:35:13 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: On Sat, 8 Nov 2025 07:10:16 GMT, Alan Bateman wrote: > For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly? Yes, that's same behavior as before. I agree jlink should handle java.base not in the module path gracefully, I will add another error message to handle that. Do we want that for target release.txt as well? Since that's currently throwing IllegalArgumentException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511227667 From iris at openjdk.org Mon Nov 10 16:35:13 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 10 Nov 2025 16:35:13 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v4] In-Reply-To: <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com> References: <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com> Message-ID: <4hRkyQC_Dpj1ojQuuFvjJEkFiFqCHqDQm_nnPjDRxfc=.c0a10797-cb7a-4987-9574-0b570acd21b0@github.com> On Mon, 10 Nov 2025 16:15:38 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Updates due to the generate-symbol-data.sh location changing in 8367259 > - Updates due to the generate-symbol-data.sh location changing in 8367259 > - Merge branch 'master' into start-of-release-27 > - update links to JVMS 26 and 27 > - add missing enum > - initial commit start-of-JDK-27 Expected changes for JDK 27 looking good. make/conf/version-numbers.conf line 36: > 34: DEFAULT_VERSION_EXTRA2=0 > 35: DEFAULT_VERSION_EXTRA3=0 > 36: DEFAULT_VERSION_DATE=2026-09-15 Anticipated GA date confirmed. ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3444133407 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2511223183 From alanb at openjdk.org Mon Nov 10 16:48:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 10 Nov 2025 16:48:50 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 16:32:41 GMT, Henry Jen wrote: >> That's right. If getReleaseInfo(current) were to fail then it suggests a JDK build or other bug. >> >> For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly? >> >> If java.base is found on the module path but it doesn't contain the release file then the updated code to use "N/A" is okay as it feeds into the error message that jlink will print. >> >> So I think the changes are nearly there. >> >> I've added the "csr" label to the PR as this change will need a CSR. There may be cases today that are cross linking successfully (they got lucky) but they will fail with the change due to the stricter check. > >> For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly? > > Yes, that's same behavior as before. I agree jlink should handle java.base not in the module path gracefully, I will add another error message to handle that. Do we want that for target release.txt as well? Since that's currently throwing IllegalArgumentException. I think this is an err.jlink.version.mismatch, of sorts, case. The user has run the jlink command with a module path containing a version of java.base that is at least one feature release old. I think a mismatch would be less confusing than an IllegalArgumentException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511266937 From henryjen at openjdk.org Mon Nov 10 17:56:36 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 10 Nov 2025 17:56:36 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: References: Message-ID: <8L7V95kBIoSQmh13eBqQqk9C1syY8k1Ry2KdFBo7unc=.818ea522-47a8-4b6f-b30f-0ba17b60b9db@github.com> On Mon, 10 Nov 2025 16:45:51 GMT, Alan Bateman wrote: >>> For the target runtime then finder.find("java.base") returning emptymeans the module path specified to jlink doesn't have java.base so this should be handled gracefully. With the current changes then it looks like it will fail up with NoSuchElementException, do I read this correctly? >> >> Yes, that's same behavior as before. I agree jlink should handle java.base not in the module path gracefully, I will add another error message to handle that. Do we want that for target release.txt as well? Since that's currently throwing IllegalArgumentException. > > I think this is an err.jlink.version.mismatch, of sorts, case. The user has run the jlink command with a module path containing a version of java.base that is at least one feature release old. I think a mismatch would be less confusing than an IllegalArgumentException. For target java.base not having release.txt will show mismatch against build "N/A". But I am thinking I will tighten it up to avoid current release.txt is have a value "N/A". What I am talking about is should we fail gracefully on current java.base for jlink not having a release.txt, which should not happen with a proper build. In that sense, an IllegalArgumentException is not that bad. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511460040 From henryjen at openjdk.org Mon Nov 10 18:22:15 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 10 Nov 2025 18:22:15 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v2] In-Reply-To: <8L7V95kBIoSQmh13eBqQqk9C1syY8k1Ry2KdFBo7unc=.818ea522-47a8-4b6f-b30f-0ba17b60b9db@github.com> References: <8L7V95kBIoSQmh13eBqQqk9C1syY8k1Ry2KdFBo7unc=.818ea522-47a8-4b6f-b30f-0ba17b60b9db@github.com> Message-ID: <-dh84-9SlqU-Gpo4nEu7gt_YUKV_D_qep1P15RjmNgo=.76d9de05-8062-430d-ab9a-c5fdb5bb4fc7@github.com> On Mon, 10 Nov 2025 17:53:50 GMT, Henry Jen wrote: >> I think this is an err.jlink.version.mismatch, of sorts, case. The user has run the jlink command with a module path containing a version of java.base that is at least one feature release old. I think a mismatch would be less confusing than an IllegalArgumentException. > > For target java.base not having release.txt will show mismatch against build "N/A". But I am thinking I will tighten it up to avoid current release.txt is have a value "N/A". > > What I am talking about is should we fail gracefully on current java.base for jlink not having a release.txt, which should not happen with a proper build. In that sense, an IllegalArgumentException is not that bad. Sorry for the confusion, if a java.base cannot be found with given module path, java.base from current jlink runtime is to be used. That has been checked in initJlinkConfig() before calling checkBaseJavaVersion. That's why NoSuchElementException is caught with an assert in the initial PR. I'll rafactor the code to make that more clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2511535066 From henryjen at openjdk.org Mon Nov 10 20:44:34 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 10 Nov 2025 20:44:34 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Refactoring to clarify version checking cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/8df7e809..68584d93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=02-03 Stats: 54 lines in 1 file changed: 27 ins; 13 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From acobbs at openjdk.org Mon Nov 10 22:24:52 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Mon, 10 Nov 2025 22:24:52 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: References: Message-ID: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - Add clarifying comment. - Merge branch 'master' into JDK-8344159 - Change inner class name to avoid shadowing superclass name. - Add a couple of code clarification comments. - Refactor test to avoid requiring changes to TestRunner. - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8 ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=04 Stats: 1667 lines in 35 files changed: 1492 ins; 49 del; 126 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From dlsmith at openjdk.org Mon Nov 10 23:46:33 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Mon, 10 Nov 2025 23:46:33 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir [v2] In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: > Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. > > I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. > > Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Remove setting of 'jspec.version' property ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28207/files - new: https://git.openjdk.org/jdk/pull/28207/files/ec6d88dd..a47c3c5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28207&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28207&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28207/head:pull/28207 PR: https://git.openjdk.org/jdk/pull/28207 From dlsmith at openjdk.org Mon Nov 10 23:52:01 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Mon, 10 Nov 2025 23:52:01 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir In-Reply-To: References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: On Sat, 8 Nov 2025 22:01:32 GMT, Chen Liang wrote: > I tested this patch on my local Linux-targeting OpenJDK WSL (because only Linux is building docs); the JVMS links become dead links in OpenJDK builds, which don't have access to JLS/JVMS, which are proprietary to Oracle. We should probably leave a comment that the dead links are intentional. Where is a good place for that comment? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28207#issuecomment-3514379165 From dlsmith at openjdk.org Tue Nov 11 00:36:30 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Tue, 11 Nov 2025 00:36:30 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir [v3] In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: > Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. > > I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. > > Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. Dan Smith has updated the pull request incrementally with one additional commit since the last revision: Comment about open-source builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28207/files - new: https://git.openjdk.org/jdk/pull/28207/files/a47c3c5a..cb8de969 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28207&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28207&range=01-02 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28207/head:pull/28207 PR: https://git.openjdk.org/jdk/pull/28207 From liach at openjdk.org Tue Nov 11 06:43:05 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 11 Nov 2025 06:43:05 GMT Subject: RFR: 8370154: Update @jls and @jvms taglets to point to local specs dir [v3] In-Reply-To: References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: <_8-tL-LF9aW4oQhg-nlEYAw6QYrXWABnKjVQnZNbFCw=.5253e893-aa69-4085-80c7-8901c9f04e00@github.com> On Tue, 11 Nov 2025 00:36:30 GMT, Dan Smith wrote: >> Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. >> >> I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. >> >> Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. > > Dan Smith has updated the pull request incrementally with one additional commit since the last revision: > > Comment about open-source builds Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28207#pullrequestreview-3446476869 From sgehwolf at openjdk.org Tue Nov 11 09:44:05 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 11 Nov 2025 09:44:05 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 20:44:34 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring to clarify version checking cases src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620: > 618: // silently ignore and fall through to version mismatch > 619: targetRelease = "missing"; > 620: } Instead of claiming that the `release.txt` file contains the string "missing", we could just throw a specific exception to that effect, no? Something along the lines of: Error: java.base module specified on the module path does not contain critical resource needed for verifying compatibility to the current runtime with version ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2513527647 From alanb at openjdk.org Tue Nov 11 10:04:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 11 Nov 2025 10:04:13 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Mon, 10 Nov 2025 20:44:34 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Refactoring to clarify version checking cases src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 589: > 587: } > 588: > 589: private static String getJlinkRuntimeVersion() { Maybe rename to getCurrentRuntimeVersion as that makes it clearer what t his method returns. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625: > 623: throw new IllegalArgumentException(taskHelper.getMessage("err.jlink.version.mismatch", > 624: currentRelease, > 625: targetRelease)); Would it be possible to paste in the error that the jlink user will see? (assuming jdk.debug is not set). I just want to be sure that the IllegalArgumentException isn't shown to the user. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2513565593 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2513579541 From jlahoda at openjdk.org Tue Nov 11 12:44:27 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 11 Nov 2025 12:44:27 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v4] In-Reply-To: <7G0o3Ph7D9I11xzojJwIXuJ4nHvNtXtQpy2BdfuZ6Kw=.b1766068-44ad-4a74-ac51-b37b191c3e65@github.com> References: <7G0o3Ph7D9I11xzojJwIXuJ4nHvNtXtQpy2BdfuZ6Kw=.b1766068-44ad-4a74-ac51-b37b191c3e65@github.com> Message-ID: <5mFMpFFAvU3VPLU8lud1zyDDXxdILSys4MoCYoVwiZI=.8fb13cf9-8e20-4aee-9c72-5d2f0fed2ece@github.com> On Thu, 6 Nov 2025 21:03:01 GMT, Archie Cobbs wrote: >> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. >> >> This can create a trap for the unwary, as in this example: >> >> public long readLongBigEndian(byte[] buf, int offset) { >> return ((buf[offset + 0] & 0xff) << 56) // BUG HERE >> | ((buf[offset + 1] & 0xff) << 48) // BUG HERE >> | ((buf[offset + 2] & 0xff) << 40) // BUG HERE >> | ((buf[offset + 3] & 0xff) << 32) // BUG HERE >> | ((buf[offset + 4] & 0xff) << 24) >> | ((buf[offset + 5] & 0xff) << 16) >> | ((buf[offset + 6] & 0xff) << 8) >> | ((buf[offset + 7] & 0xff); >> } >> >> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[-31...31]` or a `long` bit shift not in the range `[-63...63]`. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Don't warn for negative shift values that are otherwise in range. Looks good to me. I think I prefer this more conservative approach. Thanks! FWIW, from a corpus run, there are 5 cases of shift `-1`, 2 cases of shift `-5` and one cases of shift `-31`. ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27102#pullrequestreview-3447888795 PR Comment: https://git.openjdk.org/jdk/pull/27102#issuecomment-3516714885 From mbaesken at openjdk.org Tue Nov 11 14:35:58 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 11 Nov 2025 14:35:58 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries Message-ID: Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. See for example this manpage : https://manpages.debian.org/testing/lld-7/ld.lld-7.1 sizes of libjvm.so with / without -icf=all linux aarch64 : 25888 / 27112 K linux x86_64 : 27952 / 29072 K (for most other native libs the identical code folding has no effect, because there is nothing to fold) ------------- Commit messages: - JDK-8371626 Changes: https://git.openjdk.org/jdk/pull/28236/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28236&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371626 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28236/head:pull/28236 PR: https://git.openjdk.org/jdk/pull/28236 From acobbs at openjdk.org Tue Nov 11 16:21:27 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 11 Nov 2025 16:21:27 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v4] In-Reply-To: <5mFMpFFAvU3VPLU8lud1zyDDXxdILSys4MoCYoVwiZI=.8fb13cf9-8e20-4aee-9c72-5d2f0fed2ece@github.com> References: <7G0o3Ph7D9I11xzojJwIXuJ4nHvNtXtQpy2BdfuZ6Kw=.b1766068-44ad-4a74-ac51-b37b191c3e65@github.com> <5mFMpFFAvU3VPLU8lud1zyDDXxdILSys4MoCYoVwiZI=.8fb13cf9-8e20-4aee-9c72-5d2f0fed2ece@github.com> Message-ID: On Tue, 11 Nov 2025 12:41:15 GMT, Jan Lahoda wrote: > Looks good to me. I think I prefer this more conservative approach. Thanks! I am also convinced now the more conservative approach is better. Thanks for your reviews and helping nail down the best approach. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27102#issuecomment-3517690967 From mbaesken at openjdk.org Tue Nov 11 16:28:41 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 11 Nov 2025 16:28:41 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v2] In-Reply-To: References: Message-ID: > Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. > See for example this manpage : > https://manpages.debian.org/testing/lld-7/ld.lld-7.1 > > > sizes of libjvm.so with / without -icf=all > linux aarch64 : 25888 / 27112 K > linux x86_64 : 27952 / 29072 K > > > (for most other native libs the identical code folding has no effect, because there is nothing to fold) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: limit icf=all link flag to gcc + gold linker ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28236/files - new: https://git.openjdk.org/jdk/pull/28236/files/faee9051..b3caf9ab Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28236&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28236&range=00-01 Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28236/head:pull/28236 PR: https://git.openjdk.org/jdk/pull/28236 From henryjen at openjdk.org Tue Nov 11 16:38:05 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 11 Nov 2025 16:38:05 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 09:58:33 GMT, Alan Bateman wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring to clarify version checking cases > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625: > >> 623: throw new IllegalArgumentException(taskHelper.getMessage("err.jlink.version.mismatch", >> 624: currentRelease, >> 625: targetRelease)); > > Would it be possible to paste in the error that the jlink user will see? (assuming jdk.debug is not set). I just want to be sure that the IllegalArgumentException isn't shown to the user. Instead of showing N/A, it is now show missing. Output is still like above in the description. jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2514914094 From henryjen at openjdk.org Tue Nov 11 16:56:05 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 11 Nov 2025 16:56:05 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 09:41:43 GMT, Severin Gehwolf wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactoring to clarify version checking cases > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620: > >> 618: // silently ignore and fall through to version mismatch >> 619: targetRelease = "missing"; >> 620: } > > Instead of claiming that the `release.txt` file contains the string "missing", we could just throw a specific exception to that effect, no? Something along the lines of: > > > Error: java.base module specified on the module path does not contain critical resource needed for verifying compatibility to the current runtime with version Sure we can. I do want to keep a message consistent and softer as this can happen to releases before this get merged. Thought 'missing' is a little better than 'N/A' which is more likely in a release.txt. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2514962713 From henryjen at openjdk.org Tue Nov 11 17:13:06 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 11 Nov 2025 17:13:06 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 16:35:39 GMT, Henry Jen wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625: >> >>> 623: throw new IllegalArgumentException(taskHelper.getMessage("err.jlink.version.mismatch", >>> 624: currentRelease, >>> 625: targetRelease)); >> >> Would it be possible to paste in the error that the jlink user will see? (assuming jdk.debug is not set). I just want to be sure that the IllegalArgumentException isn't shown to the user. > > Instead of showing N/A, it is now show missing. Output is still like above in the description. > > > jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing IllegalArgumentException and most others are caught in run() and showing message as an Error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515013456 From dlsmith at openjdk.org Tue Nov 11 17:15:13 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Tue, 11 Nov 2025 17:15:13 GMT Subject: Integrated: 8370154: Update @jls and @jvms taglets to point to local specs dir In-Reply-To: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> References: <7-oqaURbud0FYEJF7NDLvqB5_C1QQSGKypdq2hh8XRs=.1f2c83cf-f3bb-4385-a80b-ce09636965f3@github.com> Message-ID: On Sat, 8 Nov 2025 01:29:13 GMT, Dan Smith wrote: > Updated the JSpec taglets to use relative links into `../specs/jls` and `../specs/jvms` rather than external links, possible now due to JDK-8370153. > > I was surprised there doesn't seem to be a standard way to get a relative path to the docs root, but I copy/pasted from ToolGuide, and made some tweaks based on failures I saw. > > Tested with 'make docs' and manually confirmed that a handful of different `@jls` and `@jvms` tags are pointing to the right place. This pull request has now been integrated. Changeset: c6a8027b Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/c6a8027b94bbcbde5f7dcabd0bff48b93bbb5a7f Stats: 62 lines in 3 files changed: 39 ins; 13 del; 10 mod 8370154: Update @jls and @jvms taglets to point to local specs dir Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28207 From henryjen at openjdk.org Tue Nov 11 17:19:03 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 11 Nov 2025 17:19:03 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 16:53:02 GMT, Henry Jen wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620: >> >>> 618: // silently ignore and fall through to version mismatch >>> 619: targetRelease = "missing"; >>> 620: } >> >> Instead of claiming that the `release.txt` file contains the string "missing", we could just throw a specific exception to that effect, no? Something along the lines of: >> >> >> Error: java.base module specified on the module path does not contain critical resource needed for verifying compatibility to the current runtime with version > > Sure we can. I do want to keep a message consistent and softer as this can happen to releases before this get merged. Thought 'missing' is a little better than 'N/A' which is more likely in a release.txt. Actually, if we just leave it blank, that message still works in all translation, I think. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties 81:err.jlink.version.mismatch=jlink?????{0}???????java.base?????{1}??????? src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties 81:err.jlink.version.mismatch=jlink ?? {0} ??? java.base ?? {1} ??? src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties 81:err.jlink.version.mismatch=jlink-Version {0} stimmt nicht mit Ziel-java.base-Version {1} ?berein src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties 133:err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515029024 From henryjen at openjdk.org Tue Nov 11 17:25:43 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 11 Nov 2025 17:25:43 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v5] In-Reply-To: References: Message-ID: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Treat missing release.txt as emptry release signature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/68584d93..0f1c9351 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From alanb at openjdk.org Tue Nov 11 17:30:05 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 11 Nov 2025 17:30:05 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 17:10:30 GMT, Henry Jen wrote: >> Instead of showing N/A, it is now show missing. Output is still like above in the description. >> >> >> jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing > > IllegalArgumentException and most others are caught in run() and showing message as an Error. > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing "java.base build missing" is a bit confusing as it suggests that java.base is missing when it trying to say that the release resource is missing. Have you tried creating a separate resource/message for this case? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515059195 From henryjen at openjdk.org Tue Nov 11 17:52:07 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 11 Nov 2025 17:52:07 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 17:16:40 GMT, Henry Jen wrote: >> Sure we can. I do want to keep a message consistent and softer as this can happen to releases before this get merged. Thought 'missing' is a little better than 'N/A' which is more likely in a release.txt. > > Actually, if we just leave it blank, that message still works in all translation, I think. > > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties > 81:err.jlink.version.mismatch=jlink?????{0}???????java.base?????{1}??????? > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties > 81:err.jlink.version.mismatch=jlink ?? {0} ??? java.base ?? {1} ??? > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties > 81:err.jlink.version.mismatch=jlink-Version {0} stimmt nicht mit Ziel-java.base-Version {1} ?berein > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties > 133:err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1} With the latest update, the message is like Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515113606 From henryjen at openjdk.org Tue Nov 11 17:52:09 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 11 Nov 2025 17:52:09 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 17:27:43 GMT, Alan Bateman wrote: >> IllegalArgumentException and most others are caught in run() and showing message as an Error. > >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build missing > > "java.base build missing" is a bit confusing as it suggests that java.base is missing when it trying to say that the release resource is missing. Have you tried creating a separate resource/message for this case? @jerboaa suggested the same thing, I updated the message from "missing" to "". With latest update the message is, Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build Let's use @jerboaa comment thread above to solve this message issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515111787 From sgehwolf at openjdk.org Tue Nov 11 17:59:05 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 11 Nov 2025 17:59:05 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v5] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 17:25:43 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Treat missing release.txt as emptry release signature I think this can be tested akin to `JLinkOptionsTest` by implementing a simple plugin that transforms the `release.txt` resource and uses `--keep-packaged-modules` and then attempts to perform a link on the resulting image. Similarly we could cover the case of `release.txt` missing by using the `--exclude-resources` plugin. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 620: > 618: // silently ignore and fall through to version mismatch > 619: targetRelease = ""; > 620: } You could avoid the NSEE and try/catch by handling that case explicitly: Suggestion: targetRelease = getReleaseInfo(target).orElseThrow(()-> new IllegalArgumentException("handle missing release.txt file")); if (currentRelease.equals(targetRelease)) { return; } ------------- PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3449192405 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515101026 From lmesnik at openjdk.org Tue Nov 11 18:15:23 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Nov 2025 18:15:23 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: > Please review following fix that move GC shutdown start after VM Death and agent's unloading. > > The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. > > The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: dot added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28227/files - new: https://git.openjdk.org/jdk/pull/28227/files/be6eb483..6d367b4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28227&range=02-03 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28227.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28227/head:pull/28227 PR: https://git.openjdk.org/jdk/pull/28227 From lmesnik at openjdk.org Tue Nov 11 18:33:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 11 Nov 2025 18:33:04 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence In-Reply-To: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com> References: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com> Message-ID: On Tue, 11 Nov 2025 10:03:23 GMT, Albert Mingkun Yang wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > >> move GC shutdown start after VM Death and agent's unloading > > Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)? > > (The current patch would leave GC running while calling `MemMapPrinter::print_all_mappings(tty);` -- GC can potentially alter mappings.) @albertnetymk, @stefank > > move GC shutdown start after VM Death and agent's unloading > > Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)? I updated to move jvmti code. Seems that following opertaions WatcherThread::stop(); NativeHeapTrimmer::cleanup(); might be done before sending jvmti vm_death. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3518247296 From alanb at openjdk.org Tue Nov 11 18:56:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 11 Nov 2025 18:56:09 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 17:49:40 GMT, Henry Jen wrote: >> Actually, if we just leave it blank, that message still works in all translation, I think. >> >> >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_ja.properties >> 81:err.jlink.version.mismatch=jlink?????{0}???????java.base?????{1}??????? >> >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_zh_CN.properties >> 81:err.jlink.version.mismatch=jlink ?? {0} ??? java.base ?? {1} ??? >> >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink_de.properties >> 81:err.jlink.version.mismatch=jlink-Version {0} stimmt nicht mit Ziel-java.base-Version {1} ?berein >> >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties >> 133:err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1} > > With the latest update, the message is like > > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build It kinda works but a different message to say that the release info from the java.base module is not present might be clearer. Maybe it can include something "older JDK release?" or something to give a clue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2515315980 From ayang at openjdk.org Tue Nov 11 19:05:04 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Tue, 11 Nov 2025 19:05:04 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3449515538 From sherman at openjdk.org Wed Nov 12 01:40:11 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 12 Nov 2025 01:40:11 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Fri, 7 Nov 2025 22:11:30 GMT, Roger Riggs wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use value long for folding > > src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 152: > >> 150: } >> 151: } >> 152: } > > If expanded_case_cps was sorted, Array.binarySearch could be used to find the index of the first character in the range. > And the loop could break when cp reaches the end of the range. This is the existing implementation. I will leave it to the next round when we are back to the regex. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2516389642 From duke at openjdk.org Wed Nov 12 01:40:12 2025 From: duke at openjdk.org (Shawn M Emery) Date: Wed, 12 Nov 2025 01:40:12 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v10] In-Reply-To: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> References: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> Message-ID: On Mon, 3 Nov 2025 18:50:37 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Address second set of @erikj79's build comments make/test/JtregNativeJdk.gmk line 126: > 124: # macOS: build with system krb5 and disable deprecation warnings > 125: BUILD_JDK_JTREG_LIBRARIES_LDFLAGS_libNativeCredentialCacheHelper := -lkrb5 -lcom_err > 126: BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libNativeCredentialCacheHelper := -Wno-deprecated-declarations Why doesn't the macosx target use the KRB5* variables as well? src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 2: > 1: /* > 2: * Copyright (c) 2000, 2024, Oracle and/or its affiliates. All rights reserved. nit: update copyright year src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 335: > 333: if (OperatingSystem.isWindows() || > 334: OperatingSystem.isMacOS() || > 335: OperatingSystem.isLinux()) { nit: extra tab? src/java.security.jgss/share/native/libkrb5shared/nativeccache.c line 2: > 1: /* > 2: * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved. nit: update copyright year test/jdk/sun/security/krb5/native/NativeCacheTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8123456 `@bug` annotation not relevant here test/jdk/sun/security/krb5/native/libNativeCredentialCacheHelper.c line 71: > 69: if (utf_chars == NULL) return NULL; > 70: > 71: char *result = strdup(utf_chars); Should check for NULL here test/jdk/sun/security/krb5/native/libNativeCredentialCacheHelper.c line 143: > 141: } > 142: > 143: nit: extra line ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516387392 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516256982 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516241205 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516233000 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2516271877 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2513002208 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2513007140 From sherman at openjdk.org Wed Nov 12 01:52:04 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 12 Nov 2025 01:52:04 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Fri, 7 Nov 2025 22:14:51 GMT, Roger Riggs wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use value long for folding > > src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 169: > >> 167: private static final int HASH_NEXT = 2; >> 168: >> 169: private static int[][] hashKeys(int[] keys) { > > It may be worthwhile to round up the hash modulo to a prime number to avoid unfortunate hash collisions. I did try several prime numbers. It doesn?t really help because the code points in the table are mostly sequential within one continuous category range; if there?s a hash collision, using a different prime will likely just move the collision to the next code point. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2516418571 From lmesnik at openjdk.org Wed Nov 12 02:45:47 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 12 Nov 2025 02:45:47 GMT Subject: RFR: 8371650: Add CMakeLists.txt and compile_commands.json into .gitignore Message-ID: Some IDE and LSP expect to find these files in the project root. It convenient to place them in src/hotspot, so idea and vim automatically find the root for hotspot project. This fix just add these files and some temporary dirs in my ws into .gitignore. Shouldn't harm anyone. ------------- Commit messages: - updated .gitignore Changes: https://git.openjdk.org/jdk/pull/28248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371650 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28248.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28248/head:pull/28248 PR: https://git.openjdk.org/jdk/pull/28248 From sherman at openjdk.org Wed Nov 12 03:24:42 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 12 Nov 2025 03:24:42 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v8] In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: > ### Summary > > Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. > > Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: > > **String.equalsIgnoreCase(String)** > > - Unicode-aware, locale-independent. > - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. > - Limited: does not support 1:M mapping defined in Unicode case folding. > > **Character.toLowerCase(int) / Character.toUpperCase(int)** > > - Locale-independent, single code point only. > - No support for 1:M mappings. > > **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** > > - Based on Unicode SpecialCasing.txt, supports 1:M mappings. > - Intended primarily for presentation/display, not structural case-insensitive matching. > - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. > > **1:M mapping example, U+00DF (?)** > > - String.toUpperCase(Locale.ROOT, "?") ? "SS" > - Case folding produces "ss", matching Unicode caseless comparison rules. > > > jshell> "\u00df".equalsIgnoreCase("ss") > $22 ==> false > > jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") > $24 ==> true > > > ### Motivation & Direction > > Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. > > - Unicode-compliant **full** case folding. > - Simpler, stable and more efficient case-less matching without workarounds. > - Brings Java's string comparison handling in line with other programming languages/libraries. > > This PR proposes to introduce the following comparison methods in `String` class > > - boolean equalsFoldCase(String anotherString) > - int compareToFoldCase(String anotherString) > - Comparator UNICODE_CASEFOLD_ORDER > > These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. > > *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. > However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. > > ### The New API > > See CSR https://bugs.openjd... Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: update with new test cases ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27628/files - new: https://git.openjdk.org/jdk/pull/27628/files/c21de111..6a01bf7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=06-07 Stats: 8 lines in 3 files changed: 3 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628 PR: https://git.openjdk.org/jdk/pull/27628 From kbarrett at openjdk.org Wed Nov 12 06:03:47 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 12 Nov 2025 06:03:47 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions Message-ID: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions Please review this change that adds `cppstdlib/new.hpp` as a wrapper for including ``. All existing inclusions of `` are changed to include the new wrapper. In additional to including ``, this wrapper also provides deprecation declarations to prevent the use of some facilities by HotSpot code. However, those deprecations need to be conditionalized to not apply to gtests, so this change also adds a macro definition provided by the build system for use in detecting that a header is being included by a gtest. Testing: mach5 tier1 ------------- Commit messages: - add wrapper for Changes: https://git.openjdk.org/jdk/pull/28250/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28250&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369187 Stats: 165 lines in 15 files changed: 143 ins; 22 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28250.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28250/head:pull/28250 PR: https://git.openjdk.org/jdk/pull/28250 From kbarrett at openjdk.org Wed Nov 12 06:21:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 12 Nov 2025 06:21:13 GMT Subject: RFR: 8370333: hotspot-unit-tests.md specifies wrong directory structure for tests Message-ID: Please review this change to the HotSpot unit test documentation, fixing the path where native tests are located. ------------- Commit messages: - fix path for native test location Changes: https://git.openjdk.org/jdk/pull/28251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370333 Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28251/head:pull/28251 PR: https://git.openjdk.org/jdk/pull/28251 From serb at openjdk.org Wed Nov 12 07:15:11 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 12 Nov 2025 07:15:11 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> On Mon, 10 Nov 2025 08:06:21 GMT, Matthias Baesken wrote: >I think there was the concern raised previously, that without setting it for at least one lib, nobody would use/try it and the feature would 'rot' . I see, I'll run the tests for this lib then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2517166399 From stefank at openjdk.org Wed Nov 12 07:43:06 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 12 Nov 2025 07:43:06 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions In-Reply-To: References: Message-ID: <6SO4sjrZNkftwWmo-9j7fPvB5K7e24kpCqt5UzSWWqQ=.bbb0560f-2e54-4f68-a67f-10fa35bf0afb@github.com> On Wed, 12 Nov 2025 05:49:27 GMT, Kim Barrett wrote: > 8369187: Add wrapper for that forbids use of global allocation and deallocation functions > > Please review this change that adds `cppstdlib/new.hpp` as a wrapper for > including ``. All existing inclusions of `` are changed to include > the new wrapper. > > In additional to including ``, this wrapper also provides deprecation > declarations to prevent the use of some facilities by HotSpot code. > > However, those deprecations need to be conditionalized to not apply to gtests, > so this change also adds a macro definition provided by the build system for > use in detecting that a header is being included by a gtest. > > Testing: mach5 tier1 src/hotspot/share/cppstdlib/new.hpp line 79: > 77: // Visual Studio => error C2370: '...': redefinition; different storage class > 78: #ifndef TARGET_COMPILER_visCPP > 79: [[deprecated]] extern const size_t hardware_destructive_interference_size; At cppreference this is declared as: inline constexpr size_t hardware_destructive_interference_size Is that why you're getting the Visual Studio error? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28250#discussion_r2517243907 From stefank at openjdk.org Wed Nov 12 07:44:01 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 12 Nov 2025 07:44:01 GMT Subject: RFR: 8370333: hotspot-unit-tests.md specifies wrong directory structure for tests In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 06:14:47 GMT, Kim Barrett wrote: > Please review this change to the HotSpot unit test documentation, fixing the > path where native tests are located. Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28251#pullrequestreview-3452048463 From stefank at openjdk.org Wed Nov 12 07:53:05 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 12 Nov 2025 07:53:05 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Looks good and thanks for the test! ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452083212 From kbarrett at openjdk.org Wed Nov 12 08:39:04 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 12 Nov 2025 08:39:04 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions In-Reply-To: <6SO4sjrZNkftwWmo-9j7fPvB5K7e24kpCqt5UzSWWqQ=.bbb0560f-2e54-4f68-a67f-10fa35bf0afb@github.com> References: <6SO4sjrZNkftwWmo-9j7fPvB5K7e24kpCqt5UzSWWqQ=.bbb0560f-2e54-4f68-a67f-10fa35bf0afb@github.com> Message-ID: On Wed, 12 Nov 2025 07:38:53 GMT, Stefan Karlsson wrote: >> 8369187: Add wrapper for that forbids use of global allocation and deallocation functions >> >> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for >> including ``. All existing inclusions of `` are changed to include >> the new wrapper. >> >> In additional to including ``, this wrapper also provides deprecation >> declarations to prevent the use of some facilities by HotSpot code. >> >> However, those deprecations need to be conditionalized to not apply to gtests, >> so this change also adds a macro definition provided by the build system for >> use in detecting that a header is being included by a gtest. >> >> Testing: mach5 tier1 > > src/hotspot/share/cppstdlib/new.hpp line 79: > >> 77: // Visual Studio => error C2370: '...': redefinition; different storage class >> 78: #ifndef TARGET_COMPILER_visCPP >> 79: [[deprecated]] extern const size_t hardware_destructive_interference_size; > > At cppreference this is declared as: > > inline constexpr size_t hardware_destructive_interference_size > > > Is that why you're getting the Visual Studio error? It can't be redeclared with the `[[deprecated]]` attribute using that form. `constexpr` requires an initializer, and what should the value be? And all `inline` declarations need to be "exactly the same" (which has a technical meaning somewhere that talks about equivalent token sequences). Removing `extern`, adding `inline`, or both leads to gcc to (quite correctly, I think) rejecting it as a redefinition. I think the form being used here does have the same storage class. I think both forms declare a variable with namespace scope and external linkage; C++17 6.5. And both gcc and clang accept it. I _think_ it's an MSVC bug of being overly restrictive, rather than both gcc and clang being overly permissive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28250#discussion_r2517393464 From iwalulya at openjdk.org Wed Nov 12 08:39:05 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Wed, 12 Nov 2025 08:39:05 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Marked as reviewed by iwalulya (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452233407 From kbarrett at openjdk.org Wed Nov 12 08:45:34 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 12 Nov 2025 08:45:34 GMT Subject: RFR: 8369188: Update link-time check for HotSpot uses of allocation and deallocation functions Message-ID: Please review this update to the gcc/clang link-time check to prevent HotSpot code from using the C++ global allocator. A number of overloads for allocation and deallocation functions have been added since C++03 and were missing from the list being checked for. Testing: mach5 tier1, GHA sanity tests (in progress) Locally (linux-aarch64) added uses of some of these functions and verified they caused the expected link-time failures. Manually verified applying c++filt to all the names in the updated list demangle to the expected function names. ------------- Commit messages: - update mangled name list Changes: https://git.openjdk.org/jdk/pull/28253/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28253&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369188 Stats: 34 lines in 1 file changed: 32 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28253.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28253/head:pull/28253 PR: https://git.openjdk.org/jdk/pull/28253 From mbaesken at openjdk.org Wed Nov 12 09:03:06 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 12 Nov 2025 09:03:06 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> References: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> Message-ID: On Wed, 12 Nov 2025 07:12:03 GMT, Sergey Bylokhov wrote: > I see, I'll run the tests for this lib then. Great, thanks ! Please tell if it works for you and what are the size reductions you get for the lib (mostly for gcc). Also please tell about your opinion on the configure option to enable/disable the whole 'lto on jdk native libs' . ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2517462352 From ayang at openjdk.org Wed Nov 12 11:04:21 2025 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 12 Nov 2025 11:04:21 GMT Subject: RFR: 8370333: hotspot-unit-tests.md specifies wrong directory structure for tests In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 06:14:47 GMT, Kim Barrett wrote: > Please review this change to the HotSpot unit test documentation, fixing the > path where native tests are located. Marked as reviewed by ayang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28251#pullrequestreview-3452874281 From duke at openjdk.org Wed Nov 12 11:38:05 2025 From: duke at openjdk.org (Nick Hall) Date: Wed, 12 Nov 2025 11:38:05 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v10] In-Reply-To: References: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> Message-ID: On Wed, 12 Nov 2025 00:13:27 GMT, Shawn M Emery wrote: >> Nick Hall has updated the pull request incrementally with one additional commit since the last revision: >> >> Address second set of @erikj79's build comments > > src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 335: > >> 333: if (OperatingSystem.isWindows() || >> 334: OperatingSystem.isMacOS() || >> 335: OperatingSystem.isLinux()) { > > nit: extra tab? This is the overall structure currently: if (OperatingSystem.isWindows() || OperatingSystem.isMacOS() || OperatingSystem.isLinux()) { Would you prefer the second two line up or all line up? It _looks_ like generally the JDK source I've looked at would line them all up (although that's not what was there before!)? > test/jdk/sun/security/krb5/native/libNativeCredentialCacheHelper.c line 143: > >> 141: } >> 142: >> 143: > > nit: extra line Thanks, fixed in next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2517957978 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2517961143 From duke at openjdk.org Wed Nov 12 11:42:06 2025 From: duke at openjdk.org (Nick Hall) Date: Wed, 12 Nov 2025 11:42:06 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v10] In-Reply-To: References: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> Message-ID: On Wed, 12 Nov 2025 01:36:19 GMT, Shawn M Emery wrote: >> Nick Hall has updated the pull request incrementally with one additional commit since the last revision: >> >> Address second set of @erikj79's build comments > > make/test/JtregNativeJdk.gmk line 126: > >> 124: # macOS: build with system krb5 and disable deprecation warnings >> 125: BUILD_JDK_JTREG_LIBRARIES_LDFLAGS_libNativeCredentialCacheHelper := -lkrb5 -lcom_err >> 126: BUILD_JDK_JTREG_LIBRARIES_CFLAGS_libNativeCredentialCacheHelper := -Wno-deprecated-declarations > > Why doesn't the macosx target use the KRB5* variables as well? Only because I was trying to avoid making changes there, but you're right - the resultant value of this on MacOS would be the hard-coded set of libs there, so there's no harm in using at (and potentially some advantage to people building on MacOS against a non-system version of Kerberos). Fixed in next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2517970400 From duke at openjdk.org Wed Nov 12 11:55:40 2025 From: duke at openjdk.org (Nick Hall) Date: Wed, 12 Nov 2025 11:55:40 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: Message-ID: > _Purpose_ > > This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. > > _Rationale_ > > Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. > > The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). > > Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. > > _Implementation Detail_ > > Note that there were multiple possible ways of doing this: > > 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. > > 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. > > 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. > > I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensate for this. > > Interested to hear if anyone else... Nick Hall has updated the pull request incrementally with one additional commit since the last revision: Attend to @smemery's code review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28075/files - new: https://git.openjdk.org/jdk/pull/28075/files/8c8288a3..f4a8543f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=09-10 Stats: 8 lines in 5 files changed: 2 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075 PR: https://git.openjdk.org/jdk/pull/28075 From duke at openjdk.org Wed Nov 12 11:58:03 2025 From: duke at openjdk.org (Nick Hall) Date: Wed, 12 Nov 2025 11:58:03 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v10] In-Reply-To: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> References: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> Message-ID: <2Gf8L8DssBH2K1M8P_Fal_fzKJY3OpwCT8ZwLVmQgUA=.33912153-55a6-46de-9bb9-cac1f5c04f49@github.com> On Mon, 3 Nov 2025 18:50:37 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Address second set of @erikj79's build comments @smemery have pushed fixes for your comments. I've tested the changes on Linux, but don't have a Mac here today to test the build changes - so will attend to anything that fails in the CI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3521561415 From yasuenag at gmail.com Wed Nov 12 12:57:56 2025 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 12 Nov 2025 21:57:56 +0900 Subject: Building OpenJDK with Visual Studio 2026 Message-ID: <2e60f523-5816-411f-bfd2-345d0d7a9a14@gmail.com> Hi all, Microsoft Visual Studio 2026 has been released, so I tried to build OpenJDK with it. VS 2026 has not been supported yet of course, but I did it with following patch: https://github.com/YaSuenag/jdk/commit/a96cae553573c44b6046e304caec6063d1b79c9b Can I contribute it? I want to know whether I can send PR now. Let me know someone has started to work for VS 2026, or should suspend now for some reason (e.g. roadmap for build system). Thanks, Yasumasa From stefank at openjdk.org Wed Nov 12 13:16:19 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 12 Nov 2025 13:16:19 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions In-Reply-To: References: <6SO4sjrZNkftwWmo-9j7fPvB5K7e24kpCqt5UzSWWqQ=.bbb0560f-2e54-4f68-a67f-10fa35bf0afb@github.com> Message-ID: On Wed, 12 Nov 2025 08:36:32 GMT, Kim Barrett wrote: >> src/hotspot/share/cppstdlib/new.hpp line 79: >> >>> 77: // Visual Studio => error C2370: '...': redefinition; different storage class >>> 78: #ifndef TARGET_COMPILER_visCPP >>> 79: [[deprecated]] extern const size_t hardware_destructive_interference_size; >> >> At cppreference this is declared as: >> >> inline constexpr size_t hardware_destructive_interference_size >> >> >> Is that why you're getting the Visual Studio error? > > It can't be redeclared with the `[[deprecated]]` attribute using that form. > `constexpr` requires an initializer, and what should the value be? And all > `inline` declarations need to be "exactly the same" (which has a technical > meaning somewhere that talks about equivalent token sequences). > > Removing `extern`, adding `inline`, or both leads to gcc to (quite correctly, > I think) rejecting it as a redefinition. > > I think the form being used here does have the same storage class. I think > both forms declare a variable with namespace scope and external linkage; C++17 > 6.5. And both gcc and clang accept it. I _think_ it's an MSVC bug of being > overly restrictive, rather than both gcc and clang being overly permissive. I'm still note convinced that the above does what you intended to do here, but the result seems to be the same so I guess that's fine. If I compile a small test: #include [[deprecated]] inline constexpr int my_deprecated = 1; int main() { printf("my_deprecated: %d\n", my_deprecated); return 0; } I get: $ g++ -std=c++17 -Wall -Wextra -pedantic h.cpp h.cpp:6:33: warning: 'my_deprecated' is deprecated [-Wdeprecated-declarations] 6 | printf("my_deprecated: %d\n", my_deprecated); | ^ h.cpp:3:3: note: 'my_deprecated' has been explicitly marked deprecated here 3 | [[deprecated]] inline constexpr int my_deprecated = 1; | ^ 1 warning generated. But if I try to compile something similar to the above code I don't get the deprecated warning: #include #include namespace std { [[deprecated]] extern const size_t hardware_destructive_interference_size; }; int main() { printf("x = %zu\n", std::hardware_destructive_interference_size); return 0; } Now I get: $ g++ -std=c++17 -Wall -Wextra -pedantic g.cpp g.cpp:9:28: error: reference to 'hardware_destructive_interference_size' is ambiguous 9 | printf("x = %zu\n", std::hardware_destructive_interference_size); | ~~~~~^ /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__new/interference_size.h:25:25: note: candidate found by name lookup is 'std::__1::hardware_destructive_interference_size' 25 | inline constexpr size_t hardware_destructive_interference_size = __GCC_DESTRUCTIVE_SIZE; | ^ g.cpp:5:36: note: candidate found by name lookup is 'std::hardware_destructive_interference_size' 5 | [[deprecated]] extern const size_t hardware_destructive_interference_size; | ^ 1 error generated. where the end result is that we get a warning about an ambiguous lookup and not a warning that this has been deprecated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28250#discussion_r2518263890 From jwaters at openjdk.org Wed Nov 12 13:50:05 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 12 Nov 2025 13:50:05 GMT Subject: RFR: 8369188: Update link-time check for HotSpot uses of allocation and deallocation functions In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 07:07:48 GMT, Kim Barrett wrote: > Please review this update to the gcc/clang link-time check to prevent HotSpot > code from using the C++ global allocator. A number of overloads for allocation > and deallocation functions have been added since C++03 and were missing from > the list being checked for. > > Testing: mach5 tier1, GHA sanity tests (in progress) > > Locally (linux-aarch64) added uses of some of these functions and verified > they caused the expected link-time failures. Manually verified applying > c++filt to all the names in the updated list demangle to the expected function > names. Looks good to me ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/28253#pullrequestreview-3453544361 From aboldtch at openjdk.org Wed Nov 12 14:06:32 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 12 Nov 2025 14:06:32 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added lgtm. ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3453617541 From weijun at openjdk.org Wed Nov 12 14:19:25 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 12 Nov 2025 14:19:25 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: Message-ID: <_qK2Pq7bH7zwkzKipujnNbQD8SH4t6Bamrt_lj2VaEM=.4c20d7ed-33e3-4dd4-a661-b640ff4c0b26@github.com> On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Attend to @smemery's code review comments test/jdk/sun/security/krb5/native/NativeCredentialCacheHelper.h line 1: > 1: /* DO NOT EDIT THIS FILE - it is machine generated */ Even if this is machine generated, I suggest adding the copyright header as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518482935 From weijun at openjdk.org Wed Nov 12 14:32:15 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 12 Nov 2025 14:32:15 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: Message-ID: <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com> On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Attend to @smemery's code review comments src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 536: > 534: System.loadLibrary("osxkrb5"); > 535: } else if (OperatingSystem.isLinux()) { > 536: System.loadLibrary("linuxkrb5"); Can we use the same lib name on macOS and Linux? test/jdk/sun/security/krb5/native/NativeCacheTest.java line 146: > 144: } > 145: > 146: // Fallback to the default cache if copying from file cache fails Could this happen? Will there be unexpected ticket in the default cache? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518534368 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518524200 From weijun at openjdk.org Wed Nov 12 14:55:23 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 12 Nov 2025 14:55:23 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Attend to @smemery's code review comments test/jdk/sun/security/krb5/native/NativeCacheTest.java line 124: > 122: * Copy the TGT to an in-memory cache using JNI > 123: */ > 124: private static String copyTGTToInMemoryCache() throws Exception { All native methods are called here with the same order. Is it possible to just create one single native method and do everything inside? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518628852 From duke at openjdk.org Wed Nov 12 15:15:25 2025 From: duke at openjdk.org (Nick Hall) Date: Wed, 12 Nov 2025 15:15:25 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com> References: <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com> Message-ID: On Wed, 12 Nov 2025 14:28:55 GMT, Weijun Wang wrote: >> Nick Hall has updated the pull request incrementally with one additional commit since the last revision: >> >> Attend to @smemery's code review comments > > src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 536: > >> 534: System.loadLibrary("osxkrb5"); >> 535: } else if (OperatingSystem.isLinux()) { >> 536: System.loadLibrary("linuxkrb5"); > > Can we use the same lib name on macOS and Linux? We can - this was mostly just an attempt to avoid changing MacOS for the sake of a library name - I also wasn't sure if this might lead to other packaging changes/issues for people who package JVMs for MacOS? My original approach had a single name, so it would straightforward to make this happen. What do you think? > test/jdk/sun/security/krb5/native/NativeCacheTest.java line 146: > >> 144: } >> 145: >> 146: // Fallback to the default cache if copying from file cache fails > > Could this happen? Will there be unexpected ticket in the default cache? I think this (and your other comment on the test helper) could be simplified, I'll do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518702065 PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518703906 From weijun at openjdk.org Wed Nov 12 15:39:45 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 12 Nov 2025 15:39:45 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com> Message-ID: On Wed, 12 Nov 2025 15:12:04 GMT, Nick Hall wrote: >> src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 536: >> >>> 534: System.loadLibrary("osxkrb5"); >>> 535: } else if (OperatingSystem.isLinux()) { >>> 536: System.loadLibrary("linuxkrb5"); >> >> Can we use the same lib name on macOS and Linux? > > We can - this was mostly just an attempt to avoid changing MacOS for the sake of a library name - I also wasn't sure if this might lead to other packaging changes/issues for people who package JVMs for MacOS? My original approach had a single name, so it would straightforward to make this happen. What do you think? I don't have a strong opinion. This is internal structure, but you're right if someone tries to package a macOS-only JVM they would need some change. If we want this feature to be backported, maybe it's safe to keep using the old name. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518798712 From weijun at openjdk.org Wed Nov 12 15:39:50 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 12 Nov 2025 15:39:50 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 14:53:11 GMT, Weijun Wang wrote: >> Nick Hall has updated the pull request incrementally with one additional commit since the last revision: >> >> Attend to @smemery's code review comments > > test/jdk/sun/security/krb5/native/NativeCacheTest.java line 124: > >> 122: * Copy the TGT to an in-memory cache using JNI >> 123: */ >> 124: private static String copyTGTToInMemoryCache() throws Exception { > > All native methods are called here with the same order. Is it possible to just create one single native method and do everything inside? You can even try using the latest FFM API. Not a request, just 0.01 cent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2518802974 From mbaesken at openjdk.org Wed Nov 12 15:46:09 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 12 Nov 2025 15:46:09 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: > Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. > See for example this manpage : > https://manpages.debian.org/testing/lld-7/ld.lld-7.1 > > > sizes of libjvm.so with / without -icf=all > linux aarch64 : 25888 / 27112 K > linux x86_64 : 27952 / 29072 K > > > (for most other native libs the identical code folding has no effect, because there is nothing to fold) Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Limit icf to release builds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28236/files - new: https://git.openjdk.org/jdk/pull/28236/files/b3caf9ab..cc6c3a01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28236&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28236&range=01-02 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28236.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28236/head:pull/28236 PR: https://git.openjdk.org/jdk/pull/28236 From mbaesken at openjdk.org Wed Nov 12 15:50:00 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 12 Nov 2025 15:50:00 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken wrote: >> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. >> See for example this manpage : >> https://manpages.debian.org/testing/lld-7/ld.lld-7.1 >> >> >> sizes of libjvm.so with / without -icf=all >> linux aarch64 : 25888 / 27112 K >> linux x86_64 : 27952 / 29072 K >> >> >> (for most other native libs the identical code folding has no effect, because there is nothing to fold) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Limit icf to release builds Something similar seems to be used already for MSVC https://github.com/openjdk/jdk/blob/56a27d11971d935e8b28ac9d701cf9890014a949/make/autoconf/flags-ldflags.m4#L89 `BASIC_LDFLAGS_JVM_ONLY="-opt:icf,8 -subsystem:windows"` See the icf doc at https://learn.microsoft.com/en-us/cpp/build/reference/opt-optimizations?view=msvc-170 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3522621671 From lucy at openjdk.org Wed Nov 12 16:41:44 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 12 Nov 2025 16:41:44 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken wrote: >> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. >> See for example this manpage : >> https://manpages.debian.org/testing/lld-7/ld.lld-7.1 >> >> >> sizes of libjvm.so with / without -icf=all >> linux aarch64 : 25888 / 27112 K >> linux x86_64 : 27952 / 29072 K >> >> >> (for most other native libs the identical code folding has no effect, because there is nothing to fold) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Limit icf to release builds LGTM. Surprisingly big savings. ------------- PR Review: https://git.openjdk.org/jdk/pull/28236#pullrequestreview-3454397415 From sspitsyn at openjdk.org Wed Nov 12 18:33:46 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 12 Nov 2025 18:33:46 GMT Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik wrote: >> Please review following fix that move GC shutdown start after VM Death and agent's unloading. >> >> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. >> >> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > dot added Looks good. Thank you for fixing this issue! ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3454892220 From lmesnik at openjdk.org Wed Nov 12 18:58:04 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 12 Nov 2025 18:58:04 GMT Subject: Integrated: 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik wrote: > Please review following fix that move GC shutdown start after VM Death and agent's unloading. > > The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing. > > The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling. This pull request has now been integrated. Changeset: 705bd6fb Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/705bd6fbdc0e78625d05dbfa8af547c50b076e69 Stats: 161 lines in 3 files changed: 151 ins; 9 del; 1 mod 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence Reviewed-by: ayang, stefank, iwalulya, aboldtch, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/28227 From duke at openjdk.org Wed Nov 12 22:25:08 2025 From: duke at openjdk.org (Shawn M Emery) Date: Wed, 12 Nov 2025 22:25:08 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v10] In-Reply-To: References: <20Lpz6GikCJoVCLF_B-sWm8vrxA7Gj-5p1e4gSkCl7g=.cba2409e-1b09-4ace-b94b-7e5d44e3eda9@github.com> Message-ID: On Wed, 12 Nov 2025 11:34:13 GMT, Nick Hall wrote: >> src/java.security.jgss/share/classes/sun/security/krb5/Credentials.java line 335: >> >>> 333: if (OperatingSystem.isWindows() || >>> 334: OperatingSystem.isMacOS() || >>> 335: OperatingSystem.isLinux()) { >> >> nit: extra tab? > > This is the overall structure currently: > > if (OperatingSystem.isWindows() || > OperatingSystem.isMacOS() || > OperatingSystem.isLinux()) { > > > Would you prefer the second two line up or all line up? It _looks_ like generally the JDK source I've looked at would line them all up (although that's not what was there before!)? The following would meet code conventions: if (OperatingSystem.isWindows() || OperatingSystem.isMacOS() || OperatingSystem.isLinux()) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2519995635 From kbarrett at openjdk.org Thu Nov 13 05:58:25 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 13 Nov 2025 05:58:25 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v2] In-Reply-To: References: Message-ID: > 8369187: Add wrapper for that forbids use of global allocation and deallocation functions > > Please review this change that adds `cppstdlib/new.hpp` as a wrapper for > including ``. All existing inclusions of `` are changed to include > the new wrapper. > > In additional to including ``, this wrapper also provides deprecation > declarations to prevent the use of some facilities by HotSpot code. > > However, those deprecations need to be conditionalized to not apply to gtests, > so this change also adds a macro definition provided by the build system for > use in detecting that a header is being included by a gtest. > > Testing: mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into wrap-stdlib-new - further conditionalize deprecation of hardare interference sizes - add wrapper for ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28250/files - new: https://git.openjdk.org/jdk/pull/28250/files/103f7c2b..11c088e1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28250&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28250&range=00-01 Stats: 6550 lines in 64 files changed: 2791 ins; 3375 del; 384 mod Patch: https://git.openjdk.org/jdk/pull/28250.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28250/head:pull/28250 PR: https://git.openjdk.org/jdk/pull/28250 From kbarrett at openjdk.org Thu Nov 13 05:58:25 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 13 Nov 2025 05:58:25 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v2] In-Reply-To: References: <6SO4sjrZNkftwWmo-9j7fPvB5K7e24kpCqt5UzSWWqQ=.bbb0560f-2e54-4f68-a67f-10fa35bf0afb@github.com> Message-ID: On Wed, 12 Nov 2025 13:13:04 GMT, Stefan Karlsson wrote: >> It can't be redeclared with the `[[deprecated]]` attribute using that form. >> `constexpr` requires an initializer, and what should the value be? And all >> `inline` declarations need to be "exactly the same" (which has a technical >> meaning somewhere that talks about equivalent token sequences). >> >> Removing `extern`, adding `inline`, or both leads to gcc to (quite correctly, >> I think) rejecting it as a redefinition. >> >> I think the form being used here does have the same storage class. I think >> both forms declare a variable with namespace scope and external linkage; C++17 >> 6.5. And both gcc and clang accept it. I _think_ it's an MSVC bug of being >> overly restrictive, rather than both gcc and clang being overly permissive. > > I'm still note convinced that the above does what you intended to do here, but the result seems to be the same so I guess that's fine. > > If I compile a small test: > > #include > > [[deprecated]] inline constexpr int my_deprecated = 1; > > int main() { > printf("my_deprecated: %d\n", my_deprecated); > return 0; > } > > I get: > > $ g++ -std=c++17 -Wall -Wextra -pedantic h.cpp > h.cpp:6:33: warning: 'my_deprecated' is deprecated [-Wdeprecated-declarations] > 6 | printf("my_deprecated: %d\n", my_deprecated); > | ^ > h.cpp:3:3: note: 'my_deprecated' has been explicitly marked deprecated here > 3 | [[deprecated]] inline constexpr int my_deprecated = 1; > | ^ > 1 warning generated. > > > But if I try to compile something similar to the above code I don't get the deprecated warning: > > #include > #include > > namespace std { > [[deprecated]] extern const size_t hardware_destructive_interference_size; > }; > > int main() { > printf("x = %zu\n", std::hardware_destructive_interference_size); > return 0; > } > > Now I get: > > $ g++ -std=c++17 -Wall -Wextra -pedantic g.cpp > g.cpp:9:28: error: reference to 'hardware_destructive_interference_size' is ambiguous > 9 | printf("x = %zu\n", std::hardware_destructive_interference_size); > | ~~~~~^ > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/__new/interference_size.h:25:25: note: candidate found by name lookup is 'std::__1::hardware_destructive_interference_size' > 25 | inline constexpr size_t hardware_destructive_interference_size = __GCC_DESTRUCTIVE_SIZE; > | ^ > g.cpp:5:36: note: candidate found by name lookup is 'std::hardware_destructive_interference_size' > 5 | [[deprecated]] extern const size_t hardware_destructive_interference_size; > | ^ > 1 error generated. > > where the end result is that we get a warning about an ambiguous lookup and not a warning that this has been deprecated. Getting the desired behavor seems to require a sufficiently recent compiler. Changed to only redeclare these variables deprecated accordingly. It's kind of messy. We could just skip these deprecations, though having put in the work to find good versions... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28250#discussion_r2521668787 From mbaesken at openjdk.org Thu Nov 13 08:17:20 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 13 Nov 2025 08:17:20 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken wrote: >> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. >> See for example this manpage : >> https://manpages.debian.org/testing/lld-7/ld.lld-7.1 >> >> >> sizes of libjvm.so with / without -icf=all >> linux aarch64 : 25888 / 27112 K >> linux x86_64 : 27952 / 29072 K >> >> >> (for most other native libs the identical code folding has no effect, because there is nothing to fold) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Limit icf to release builds Hi Lutz , thanks for the review ! Questions to all - should I add a configure flag for this to enable/disable it? Should I limit it to libjvm like it was done with the opt:icf,8 setting on Windows (background is that for most other libs there is not much to 'fold' so there the saving are very small or zero. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3526299914 From kbarrett at openjdk.org Thu Nov 13 08:36:25 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 13 Nov 2025 08:36:25 GMT Subject: RFR: 8370333: hotspot-unit-tests.md specifies wrong directory structure for tests In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 07:41:28 GMT, Stefan Karlsson wrote: >> Please review this change to the HotSpot unit test documentation, fixing the >> path where native tests are located. > > Marked as reviewed by stefank (Reviewer). Thanks for reviews @stefank and @albertnetymk ------------- PR Comment: https://git.openjdk.org/jdk/pull/28251#issuecomment-3526423827 From kbarrett at openjdk.org Thu Nov 13 08:36:26 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 13 Nov 2025 08:36:26 GMT Subject: Integrated: 8370333: hotspot-unit-tests.md specifies wrong directory structure for tests In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 06:14:47 GMT, Kim Barrett wrote: > Please review this change to the HotSpot unit test documentation, fixing the > path where native tests are located. This pull request has now been integrated. Changeset: 795ec5c1 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/795ec5c1e90309bc008acb28cfe0ce039dabcb8f Stats: 8 lines in 2 files changed: 0 ins; 0 del; 8 mod 8370333: hotspot-unit-tests.md specifies wrong directory structure for tests Reviewed-by: stefank, ayang ------------- PR: https://git.openjdk.org/jdk/pull/28251 From duke at openjdk.org Thu Nov 13 10:10:27 2025 From: duke at openjdk.org (Nick Hall) Date: Thu, 13 Nov 2025 10:10:27 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: <-S7R7tafpyU8i0p6qkySw3Brq3_fVtv7ZJFUhx4yVUU=.145b6f0a-5a04-4a91-9f3a-cfa41599ec3d@github.com> Message-ID: On Wed, 12 Nov 2025 15:35:42 GMT, Weijun Wang wrote: >> We can - this was mostly just an attempt to avoid changing MacOS for the sake of a library name - I also wasn't sure if this might lead to other packaging changes/issues for people who package JVMs for MacOS? My original approach had a single name, so it would straightforward to make this happen. What do you think? > > I don't have a strong opinion. This is internal structure, but you're right if someone tries to package a macOS-only JVM they would need some change. If we want this feature to be backported, maybe it's safe to keep using the old name. I can only speak for myself/my employer, but we would find utility in this feature being backported for sure. I'll leave as-is for now, but happy to adjust in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2522730226 From duke at openjdk.org Thu Nov 13 10:30:39 2025 From: duke at openjdk.org (Nick Hall) Date: Thu, 13 Nov 2025 10:30:39 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:36:46 GMT, Weijun Wang wrote: >> test/jdk/sun/security/krb5/native/NativeCacheTest.java line 124: >> >>> 122: * Copy the TGT to an in-memory cache using JNI >>> 123: */ >>> 124: private static String copyTGTToInMemoryCache() throws Exception { >> >> All native methods are called here with the same order. Is it possible to just create one single native method and do everything inside? > > You can even try using the latest FFM API. Not a request, just 0.01 cent. I've updated this as requested in the next set of commits (much simpler given this is just a test helper). I'll leave as JNI for now, because this improves the ability for this to be backported to earlier versions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2522825810 From duke at openjdk.org Thu Nov 13 11:02:21 2025 From: duke at openjdk.org (Nick Hall) Date: Thu, 13 Nov 2025 11:02:21 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: Message-ID: > _Purpose_ > > This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. > > _Rationale_ > > Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. > > The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). > > Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. > > _Implementation Detail_ > > Note that there were multiple possible ways of doing this: > > 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. > > 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. > > 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. > > I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensate for this. > > Interested to hear if anyone else... Nick Hall has updated the pull request incrementally with three additional commits since the last revision: - Small doc fix - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates - Attend to remaining comments from @smemery ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28075/files - new: https://git.openjdk.org/jdk/pull/28075/files/f4a8543f..d7ea6c9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=10-11 Stats: 275 lines in 5 files changed: 69 ins; 147 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/28075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075 PR: https://git.openjdk.org/jdk/pull/28075 From duke at openjdk.org Thu Nov 13 11:02:24 2025 From: duke at openjdk.org (Nick Hall) Date: Thu, 13 Nov 2025 11:02:24 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v11] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 11:55:40 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Attend to @smemery's code review comments @smemery @wangweij have pushed some commits addressing your requested changes - thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527221313 From duke at openjdk.org Thu Nov 13 11:13:18 2025 From: duke at openjdk.org (Bernd) Date: Thu, 13 Nov 2025 11:13:18 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with three additional commits since the last revision: > > - Small doc fix > - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates > - Attend to remaining comments from @smemery Thanks for the work and maybe sorry for a dumb question but maybe it helps with documentation - if i get this right this only works for cases where the native client actually can extract the key credentials but not for things where a external component would be needed to apply them (like ssdp, tpm, sssd and the like, right?) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527284675 From duke at openjdk.org Thu Nov 13 11:38:24 2025 From: duke at openjdk.org (Nick Hall) Date: Thu, 13 Nov 2025 11:38:24 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: Message-ID: <4eOyzxFSjWagfXUPVXtIT57FXFud9OSgvsEzW6IHre0=.cae874d5-503a-4ba8-b8dc-6c5a886e4746@github.com> On Thu, 13 Nov 2025 11:09:49 GMT, Bernd wrote: > Thanks for the work and maybe sorry for a dumb question but maybe it helps with documentation - if i get this right this only works for cases where the native client actually can extract the key credentials but not for things where a external component would be needed to apply them (like ssdp, tpm, sssd and the like, right?) Assuming I've understood your question: - this works for all cases where the system libraries could get to a TGT in a ccache - so FILE:, MEMORY:, KEYRING:, KCM:, etc. For things like `sssd`, assuming that's using the `sssd` KCM implementation, that should work (we use KCM here, though not `sssd`'s implementation). - If something else is needed to extract/convert a secret that's stored in another place and use it as a key to get a TGT from the KDC, this wouldn't help, although as you can hopefully see from the test helper, once you've got the TGT in Java, it wouldn't be that hard to have a set of JNI helper functions so that it could be _written_ to the right ccache type (as opposed to now, when this would have to be a FILE: ccache). My reading of the way this works in JAAS currently though is that any acquired key/keytab etc is only written to the private credentials in the `javax.security.auth.Subject` object, and never actually written back to the ccache. Was that what you were getting at? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527396396 From duke at openjdk.org Thu Nov 13 11:53:19 2025 From: duke at openjdk.org (Nick Hall) Date: Thu, 13 Nov 2025 11:53:19 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with three additional commits since the last revision: > > - Small doc fix > - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates > - Attend to remaining comments from @smemery I'm not sure if there's precedent for it in other `java.security.Principal` types that JAAS can operate on, but it wouldn't be that hard to enhance the JAAS `Krb5LoginModule` to accept a new piece of JAAS configuration that would cause it to write the acquired credential back to an actual ccache as part of storing the keys during commit (within the limits of the local system arrangements - e.g. this wouldn't work on Windows because of the way LSASS protects the ccache, but likely works in Linux/MacOS cases using natively supported cache types). That said, it's not clear that's needed for client applications that use the various security frameworks / principals in the JVM (where the stored keys in the principal are used), but could be useful for helper applications written in Java that do some kind of credential exchange to create a TGT, or perhaps things written partly in JNI. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3527448204 From aseoane at openjdk.org Thu Nov 13 13:08:55 2025 From: aseoane at openjdk.org (Anton Seoane Ampudia) Date: Thu, 13 Nov 2025 13:08:55 GMT Subject: RFR: 8356761: IGV: dump escape analysis information [v7] In-Reply-To: References: Message-ID: <5suodwTPhZZL7ePO1xcs66CmiGb8Vbpg4mxSR3b0zAw=.9582b117-3949-4796-ad5b-35df6af62fda@github.com> > This PR introduces new IGV dumps, property fields and filters related to escape analysis information. > > The C2 escape analysis algorithm is carried out in six primary steps, of which many have interesting sub-steps (e.g. `split_unique_types`) or present an iterative nature where access to intermediate results can aid debugging and analysis. Additionally, escape analysis relies on an "intermediate structure" called the _connection graph_, which is also particularly valuable for deeper investigations. > > With this changeset, escape analysis information is now dumped at key points throughout the algorithm, with a degree of granularity (from only the basic steps to in-detail iterative dumping). The dumps include several property fields, such as: > > - Node escape ?level?. > - Scalar replaceability. > - Node type within the connection graph (per [C2 Escape Analysis connection graph](https://wiki.openjdk.org/display/HotSpot/EscapeAnalysis)). > > This is achieved by passing the `ConnectionGraph` in use to the `IdealGraphPrinter` during escape analysis, so that these properties can be dumped. After escape analysis, remaining interesting information that is left until macro elimination (and consequent elimination of non-escaping, replaceable allocations) is also dumped. > > Additionally, two filters are provided: one for displaying the connection node type in the IGV node box, and another one for color-scaling nodes based on their escaping/scalar status. > > **Testing:** passes tiers 1-3, manual testing in IGV Anton Seoane Ampudia has updated the pull request incrementally with two additional commits since the last revision: - Remove build files - Review comments: use `should_print_igv` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28060/files - new: https://git.openjdk.org/jdk/pull/28060/files/64bacdc2..311c7ff2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28060&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28060&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28060.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28060/head:pull/28060 PR: https://git.openjdk.org/jdk/pull/28060 From rcastanedalo at openjdk.org Thu Nov 13 13:08:58 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Thu, 13 Nov 2025 13:08:58 GMT Subject: RFR: 8356761: IGV: dump escape analysis information [v7] In-Reply-To: <5suodwTPhZZL7ePO1xcs66CmiGb8Vbpg4mxSR3b0zAw=.9582b117-3949-4796-ad5b-35df6af62fda@github.com> References: <5suodwTPhZZL7ePO1xcs66CmiGb8Vbpg4mxSR3b0zAw=.9582b117-3949-4796-ad5b-35df6af62fda@github.com> Message-ID: On Thu, 13 Nov 2025 13:04:49 GMT, Anton Seoane Ampudia wrote: >> This PR introduces new IGV dumps, property fields and filters related to escape analysis information. >> >> The C2 escape analysis algorithm is carried out in six primary steps, of which many have interesting sub-steps (e.g. `split_unique_types`) or present an iterative nature where access to intermediate results can aid debugging and analysis. Additionally, escape analysis relies on an "intermediate structure" called the _connection graph_, which is also particularly valuable for deeper investigations. >> >> With this changeset, escape analysis information is now dumped at key points throughout the algorithm, with a degree of granularity (from only the basic steps to in-detail iterative dumping). The dumps include several property fields, such as: >> >> - Node escape ?level?. >> - Scalar replaceability. >> - Node type within the connection graph (per [C2 Escape Analysis connection graph](https://wiki.openjdk.org/display/HotSpot/EscapeAnalysis)). >> >> This is achieved by passing the `ConnectionGraph` in use to the `IdealGraphPrinter` during escape analysis, so that these properties can be dumped. After escape analysis, remaining interesting information that is left until macro elimination (and consequent elimination of non-escaping, replaceable allocations) is also dumped. >> >> Additionally, two filters are provided: one for displaying the connection node type in the IGV node box, and another one for color-scaling nodes based on their escaping/scalar status. >> >> **Testing:** passes tiers 1-3, manual testing in IGV > > Anton Seoane Ampudia has updated the pull request incrementally with two additional commits since the last revision: > > - Remove build files > - Review comments: use `should_print_igv` Changes requested by rcastanedalo (Reviewer). make/hs_err_pid70657.log line 1: > 1: # Please remove. make/replay_pid70657.log line 1: > 1: version 2 Remove. ------------- PR Review: https://git.openjdk.org/jdk/pull/28060#pullrequestreview-3459688355 PR Review Comment: https://git.openjdk.org/jdk/pull/28060#discussion_r2523384072 PR Review Comment: https://git.openjdk.org/jdk/pull/28060#discussion_r2523384498 From aseoane at openjdk.org Thu Nov 13 13:08:59 2025 From: aseoane at openjdk.org (Anton Seoane Ampudia) Date: Thu, 13 Nov 2025 13:08:59 GMT Subject: RFR: 8356761: IGV: dump escape analysis information [v7] In-Reply-To: References: <5suodwTPhZZL7ePO1xcs66CmiGb8Vbpg4mxSR3b0zAw=.9582b117-3949-4796-ad5b-35df6af62fda@github.com> Message-ID: On Thu, 13 Nov 2025 13:00:48 GMT, Roberto Casta?eda Lozano wrote: >> Anton Seoane Ampudia has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove build files >> - Review comments: use `should_print_igv` > > make/hs_err_pid70657.log line 1: > >> 1: # > > Please remove. My bad. Realized as it was pushing. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28060#discussion_r2523396317 From henryjen at openjdk.org Thu Nov 13 15:42:16 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 13 Nov 2025 15:42:16 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v6] In-Reply-To: References: Message-ID: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Update the error message when not finding release signature ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/0f1c9351..fa30f2c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=04-05 Stats: 20 lines in 2 files changed: 5 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From henryjen at openjdk.org Thu Nov 13 19:59:47 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 13 Nov 2025 19:59:47 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v7] In-Reply-To: References: Message-ID: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request incrementally with one additional commit since the last revision: remove the extra space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/fa30f2c2..5fb443b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From henryjen at openjdk.org Thu Nov 13 19:59:48 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 13 Nov 2025 19:59:48 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v4] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 18:52:17 GMT, Alan Bateman wrote: >> With the latest update, the message is like >> >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build > > It kinda works but a different message to say that the release info from the java.base module is not present might be clearer. Maybe it can include something "older JDK release?" or something to give a clue. Message updated with latest commit as proposed in the CSR. $ jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 cannot find the build signature in the java.base specified on module path, likely from an earlier build. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2524746666 From stefank at openjdk.org Fri Nov 14 06:44:14 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 14 Nov 2025 06:44:14 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v2] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 05:58:25 GMT, Kim Barrett wrote: >> 8369187: Add wrapper for that forbids use of global allocation and deallocation functions >> >> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for >> including ``. All existing inclusions of `` are changed to include >> the new wrapper. >> >> In additional to including ``, this wrapper also provides deprecation >> declarations to prevent the use of some facilities by HotSpot code. >> >> However, those deprecations need to be conditionalized to not apply to gtests, >> so this change also adds a macro definition provided by the build system for >> use in detecting that a header is being included by a gtest. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into wrap-stdlib-new > - further conditionalize deprecation of hardare interference sizes > - add wrapper for Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28250#pullrequestreview-3463053286 From nbenalla at openjdk.org Fri Nov 14 09:47:49 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 14 Nov 2025 09:47:49 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v5] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into start-of-release-27 - Updates due to the generate-symbol-data.sh location changing in 8367259 - Updates due to the generate-symbol-data.sh location changing in 8367259 - Merge branch 'master' into start-of-release-27 - update links to JVMS 26 and 27 - add missing enum - initial commit start-of-JDK-27 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/0652d5d3..3d9eb308 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=03-04 Stats: 14293 lines in 184 files changed: 9629 ins; 3659 del; 1005 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From hannesw at openjdk.org Fri Nov 14 10:07:07 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 14 Nov 2025 10:07:07 GMT Subject: RFR: 8366094: Sealed graph for nested types creates broken links [v3] In-Reply-To: References: Message-ID: <-k6Pl4zkJCrLubFltPYXsWTUVMql0gszWG-5JRgQwe4=.045b6320-07c3-4c50-8580-8a158bb00af5@github.com> > Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs must have a matching `../` for each enclosing type. > > Fixed graphs for some nested sealed types: > - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html) > - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html) > - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) > > There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828). Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Add comment to explain SVG naming scheme ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28134/files - new: https://git.openjdk.org/jdk/pull/28134/files/eb3c1ec3..ef36422e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28134&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28134&range=01-02 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28134.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28134/head:pull/28134 PR: https://git.openjdk.org/jdk/pull/28134 From hannesw at openjdk.org Fri Nov 14 10:08:45 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Fri, 14 Nov 2025 10:08:45 GMT Subject: RFR: 8366094: Sealed graph for nested types creates broken links [v2] In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 16:17:54 GMT, Hannes Walln?fer wrote: >> Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs must have a matching `../` for each enclosing type. >> >> Fixed graphs for some nested sealed types: >> - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html) >> - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html) >> - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) >> >> There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828). > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year I added a comment and updated the description to better explain the problem and fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28134#issuecomment-3531955266 From sgehwolf at openjdk.org Fri Nov 14 10:18:19 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 14 Nov 2025 10:18:19 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v7] In-Reply-To: References: Message-ID: <0-JPrDhiMtDA6duzh8iGjTYImz1AqCIXy9U-HSjEVR0=.9bcd2751-d97b-4e11-a584-3527c46925f2@github.com> On Thu, 13 Nov 2025 19:59:47 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > remove the extra space src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 604: > 602: * > 603: * @throws IllegalArgumentException This jlink cannot be used to create > 604: * the target runtime image. Suggestion: * @throws IllegalArgumentException If the `java.base` module reference `target` is not compatible with this jlink. src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 615: > 613: } > 614: > 615: var targetRelease = releaseInfo.get(); This can be simplified: String targetRelease = getReleaseInfo(target).orElseThrow(() -> new IllegalArgumentException(taskHelper...)); src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 133: > 131: err.empty.module.path=No module found in module path ''{0}'' with --add-modules ALL-MODULE-PATH > 132: err.limit.modules=--limit-modules not allowed with --add-modules ALL-MODULE-PATH > 133: err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1} It would be good if the build info in the error is quoted. It's otherwise hard to discern where the build info starts/ends in the message: Suggestion: err.jlink.version.mismatch=jlink build ''{0}'' does not match target java.base build ''{1}'' src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 134: > 132: err.limit.modules=--limit-modules not allowed with --add-modules ALL-MODULE-PATH > 133: err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1} > 134: err.jlink.version.missing=jlink build {0} cannot find the build signature\ Suggestion: err.jlink.version.missing=jlink build ''{0}'' cannot find the build signature\ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526889972 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526868718 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526873977 PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2526875224 From mbaesken at openjdk.org Fri Nov 14 10:52:11 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Nov 2025 10:52:11 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken wrote: >> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. >> See for example this manpage : >> https://manpages.debian.org/testing/lld-7/ld.lld-7.1 >> >> >> sizes of libjvm.so with / without -icf=all >> linux aarch64 : 25888 / 27112 K >> linux x86_64 : 27952 / 29072 K >> >> >> (for most other native libs the identical code folding has no effect, because there is nothing to fold) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Limit icf to release builds @erikj79 , @dholmes-ora maybe some comments from you about this ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3532150530 From mbaesken at openjdk.org Fri Nov 14 11:33:34 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 14 Nov 2025 11:33:34 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size Message-ID: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : (before -> after setting the option) 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib 264K -> 248K images/jdk/lib/libjavajpeg.dylib 152K -> 132K images/jdk/lib/libjli.dylib 388K -> 296K images/jdk/lib/liblcms.dylib 164K -> 128K images/jdk/lib/libzip.dylib and libjvm : 20M -> 18M images/jdk/lib/server/libjvm.dylib 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM ------------- Commit messages: - JDK-8371893 Changes: https://git.openjdk.org/jdk/pull/28319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371893 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28319/head:pull/28319 PR: https://git.openjdk.org/jdk/pull/28319 From alanb at openjdk.org Fri Nov 14 13:43:41 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 14 Nov 2025 13:43:41 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v7] In-Reply-To: <0-JPrDhiMtDA6duzh8iGjTYImz1AqCIXy9U-HSjEVR0=.9bcd2751-d97b-4e11-a584-3527c46925f2@github.com> References: <0-JPrDhiMtDA6duzh8iGjTYImz1AqCIXy9U-HSjEVR0=.9bcd2751-d97b-4e11-a584-3527c46925f2@github.com> Message-ID: On Fri, 14 Nov 2025 10:10:21 GMT, Severin Gehwolf wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove the extra space > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 133: > >> 131: err.empty.module.path=No module found in module path ''{0}'' with --add-modules ALL-MODULE-PATH >> 132: err.limit.modules=--limit-modules not allowed with --add-modules ALL-MODULE-PATH >> 133: err.jlink.version.mismatch=jlink build {0} does not match target java.base build {1} > > It would be good if the build info in the error is quoted. It's otherwise hard to discern where the build info starts/ends in the message: > > Suggestion: > > err.jlink.version.mismatch=jlink build ''{0}'' does not match target java.base build ''{1}'' I agree as there are several sub-components in this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2527545554 From kurt at openjdk.org Fri Nov 14 15:29:45 2025 From: kurt at openjdk.org (Kurt Miller) Date: Fri, 14 Nov 2025 15:29:45 GMT Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors with external libpng Message-ID: When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64: `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]` This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX. ------------- Commit messages: - Only add libpng defines to CFLAGS when using internal libpng. Changes: https://git.openjdk.org/jdk/pull/28324/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28324&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371914 Stats: 37 lines in 1 file changed: 18 ins; 18 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28324.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28324/head:pull/28324 PR: https://git.openjdk.org/jdk/pull/28324 From henryjen at openjdk.org Fri Nov 14 16:00:43 2025 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 14 Nov 2025 16:00:43 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v8] In-Reply-To: References: Message-ID: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request incrementally with one additional commit since the last revision: adapt review feedbacks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/5fb443b2..a3edf9ac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=06-07 Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From weijun at openjdk.org Fri Nov 14 19:33:06 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Nov 2025 19:33:06 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with three additional commits since the last revision: > > - Small doc fix > - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates > - Attend to remaining comments from @smemery test/jdk/sun/security/krb5/native/NativeCredentialCacheHelper.java line 50: > 48: public static native boolean createInMemoryCacheFromFileCache(String inMemoryCacheName, String fileCacheName); > 49: } > 50: There are 2 newlines at the end. One is enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2528699601 From acobbs at openjdk.org Fri Nov 14 21:25:40 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 14 Nov 2025 21:25:40 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v5] In-Reply-To: References: Message-ID: > When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. > > This can create a trap for the unwary, as in this example: > > public long readLongBigEndian(byte[] buf, int offset) { > return ((buf[offset + 0] & 0xff) << 56) // BUG HERE > | ((buf[offset + 1] & 0xff) << 48) // BUG HERE > | ((buf[offset + 2] & 0xff) << 40) // BUG HERE > | ((buf[offset + 3] & 0xff) << 32) // BUG HERE > | ((buf[offset + 4] & 0xff) << 24) > | ((buf[offset + 5] & 0xff) << 16) > | ((buf[offset + 6] & 0xff) << 8) > | ((buf[offset + 7] & 0xff); > } > > This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[-31...31]` or a `long` bit shift not in the range `[-63...63]`. Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: Add more verbosity to "lossy-conversions" description in @SuppressWarnings table. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27102/files - new: https://git.openjdk.org/jdk/pull/27102/files/4156e813..dc326cd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27102&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27102.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27102/head:pull/27102 PR: https://git.openjdk.org/jdk/pull/27102 From acobbs at openjdk.org Fri Nov 14 21:37:38 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 14 Nov 2025 21:37:38 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v4] In-Reply-To: <5mFMpFFAvU3VPLU8lud1zyDDXxdILSys4MoCYoVwiZI=.8fb13cf9-8e20-4aee-9c72-5d2f0fed2ece@github.com> References: <7G0o3Ph7D9I11xzojJwIXuJ4nHvNtXtQpy2BdfuZ6Kw=.b1766068-44ad-4a74-ac51-b37b191c3e65@github.com> <5mFMpFFAvU3VPLU8lud1zyDDXxdILSys4MoCYoVwiZI=.8fb13cf9-8e20-4aee-9c72-5d2f0fed2ece@github.com> Message-ID: On Tue, 11 Nov 2025 12:40:45 GMT, Jan Lahoda wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't warn for negative shift values that are otherwise in range. > > FWIW, from a corpus run, there are 5 cases of shift `-1`, 2 cases of shift `-5` and one cases of shift `-31`. @lahodaj, please re-review when convenient after doc-only changes requested by @jddarcy. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27102#issuecomment-3534668366 From darcy at openjdk.org Fri Nov 14 21:44:01 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 14 Nov 2025 21:44:01 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v5] In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 21:25:40 GMT, Archie Cobbs wrote: >> When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. >> >> This can create a trap for the unwary, as in this example: >> >> public long readLongBigEndian(byte[] buf, int offset) { >> return ((buf[offset + 0] & 0xff) << 56) // BUG HERE >> | ((buf[offset + 1] & 0xff) << 48) // BUG HERE >> | ((buf[offset + 2] & 0xff) << 40) // BUG HERE >> | ((buf[offset + 3] & 0xff) << 32) // BUG HERE >> | ((buf[offset + 4] & 0xff) << 24) >> | ((buf[offset + 5] & 0xff) << 16) >> | ((buf[offset + 6] & 0xff) << 8) >> | ((buf[offset + 7] & 0xff); >> } >> >> This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[-31...31]` or a `long` bit shift not in the range `[-63...63]`. > > Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: > > Add more verbosity to "lossy-conversions" description in @SuppressWarnings table. Approving additional changes requested in CSR review. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27102#pullrequestreview-3466929946 From weijun at openjdk.org Fri Nov 14 23:51:34 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 14 Nov 2025 23:51:34 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: Message-ID: <7eI7zey61hqLAL04UNE9DC82k86ulBvKp2kyr3ITA7M=.33adeb69-8c1f-4a49-b166-4c3d9c8b1657@github.com> On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with three additional commits since the last revision: > > - Small doc fix > - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates > - Attend to remaining comments from @smemery test/jdk/sun/security/krb5/native/NativeCacheTest.java line 37: > 35: * --add-exports java.security.jgss/sun.security.jgss.krb5=ALL-UNNAMED > 36: * --add-exports java.base/sun.security.util=ALL-UNNAMED > 37: * --add-exports java.base/jdk.internal.misc=ALL-UNNAMED Use @modules java.security.jgss/sun.security.krb5 java.security.jgss/sun.security.krb5.internal ... It applies to both compile and run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28075#discussion_r2529265765 From sherman at openjdk.org Fri Nov 14 23:55:04 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 14 Nov 2025 23:55:04 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v9] In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: > ### Summary > > Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. > > Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: > > **String.equalsIgnoreCase(String)** > > - Unicode-aware, locale-independent. > - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. > - Limited: does not support 1:M mapping defined in Unicode case folding. > > **Character.toLowerCase(int) / Character.toUpperCase(int)** > > - Locale-independent, single code point only. > - No support for 1:M mappings. > > **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** > > - Based on Unicode SpecialCasing.txt, supports 1:M mappings. > - Intended primarily for presentation/display, not structural case-insensitive matching. > - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. > > **1:M mapping example, U+00DF (?)** > > - String.toUpperCase(Locale.ROOT, "?") ? "SS" > - Case folding produces "ss", matching Unicode caseless comparison rules. > > > jshell> "\u00df".equalsIgnoreCase("ss") > $22 ==> false > > jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") > $24 ==> true > > > ### Motivation & Direction > > Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. > > - Unicode-compliant **full** case folding. > - Simpler, stable and more efficient case-less matching without workarounds. > - Brings Java's string comparison handling in line with other programming languages/libraries. > > This PR proposes to introduce the following comparison methods in `String` class > > - boolean equalsFoldCase(String anotherString) > - int compareToFoldCase(String anotherString) > - Comparator UNICODE_CASEFOLD_ORDER > > These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. > > *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. > However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. > > ### The New API > > See CSR https://bugs.openjd... Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - update string class doc - Merge remote-tracking branch 'upstream/master' into JDK-8365675 sync with master - update with new test cases - update to use value long for folding - small update - update - test case update - performance update - minor api doc updates - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8365675 - ... and 1 more: https://git.openjdk.org/jdk/compare/7aff8e15...057ea814 ------------- Changes: https://git.openjdk.org/jdk/pull/27628/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=08 Stats: 1448 lines in 13 files changed: 1236 ins; 207 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/27628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628 PR: https://git.openjdk.org/jdk/pull/27628 From acobbs at openjdk.org Fri Nov 14 23:56:21 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 14 Nov 2025 23:56:21 GMT Subject: RFR: 5038439: Warning message for literal shift amounts outside the canonical domain [v4] In-Reply-To: <5mFMpFFAvU3VPLU8lud1zyDDXxdILSys4MoCYoVwiZI=.8fb13cf9-8e20-4aee-9c72-5d2f0fed2ece@github.com> References: <7G0o3Ph7D9I11xzojJwIXuJ4nHvNtXtQpy2BdfuZ6Kw=.b1766068-44ad-4a74-ac51-b37b191c3e65@github.com> <5mFMpFFAvU3VPLU8lud1zyDDXxdILSys4MoCYoVwiZI=.8fb13cf9-8e20-4aee-9c72-5d2f0fed2ece@github.com> Message-ID: On Tue, 11 Nov 2025 12:40:45 GMT, Jan Lahoda wrote: >> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision: >> >> Don't warn for negative shift values that are otherwise in range. > > FWIW, from a corpus run, there are 5 cases of shift `-1`, 2 cases of shift `-5` and one cases of shift `-31`. @lahodaj nevermind, @jddarcy got it! Thanks to both of you for reviewing & improving. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27102#issuecomment-3535081725 From acobbs at openjdk.org Fri Nov 14 23:56:24 2025 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 14 Nov 2025 23:56:24 GMT Subject: Integrated: 5038439: Warning message for literal shift amounts outside the canonical domain In-Reply-To: References: Message-ID: <7qucylknrmQ6DgoDuDzgnMnzpFtS0rPuQHrStqQ87oU=.4c90f4b6-d648-4c7a-9fb8-6cd1712d869c@github.com> On Thu, 4 Sep 2025 15:22:57 GMT, Archie Cobbs wrote: > When bit shifting an `int` or `long` value by an amount `X`, all but the last 5 or 6 (respectively) bits of `X` are ignored. > > This can create a trap for the unwary, as in this example: > > public long readLongBigEndian(byte[] buf, int offset) { > return ((buf[offset + 0] & 0xff) << 56) // BUG HERE > | ((buf[offset + 1] & 0xff) << 48) // BUG HERE > | ((buf[offset + 2] & 0xff) << 40) // BUG HERE > | ((buf[offset + 3] & 0xff) << 32) // BUG HERE > | ((buf[offset + 4] & 0xff) << 24) > | ((buf[offset + 5] & 0xff) << 16) > | ((buf[offset + 6] & 0xff) << 8) > | ((buf[offset + 7] & 0xff); > } > > This PR adds a new warning when the compiler detects an out-of-range bit shift, i.e., an `int` bit shift not in the range `[-31...31]` or a `long` bit shift not in the range `[-63...63]`. This pull request has now been integrated. Changeset: bc928c81 Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/bc928c814b5ea70505e362a643e18664e119bce3 Stats: 187 lines in 10 files changed: 183 ins; 0 del; 4 mod 5038439: Warning message for literal shift amounts outside the canonical domain Reviewed-by: darcy, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/27102 From sherman at openjdk.org Fri Nov 14 23:57:11 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 14 Nov 2025 23:57:11 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Fri, 7 Nov 2025 22:19:03 GMT, Roger Riggs wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use value long for folding > > test/jdk/java/lang/String/UnicodeCaseFoldingTest.java line 31: > >> 29: * @compile --add-exports java.base/jdk.internal.lang=ALL-UNNAMED >> 30: * UnicodeCaseFoldingTest.java >> 31: * @run junit/othervm --add-exports java.base/jdk.internal.lang=ALL-UNNAMED > > The @module directive can replace the explicit --add-exports and the explicit @compile may be unnecessary. > > * @modules java.base/jdk.internal.lang:+open updated as suggested ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2529280093 From sherman at openjdk.org Sat Nov 15 01:22:12 2025 From: sherman at openjdk.org (Xueming Shen) Date: Sat, 15 Nov 2025 01:22:12 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v7] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: <9jpJ-i9OwkJeyIcrnzm5wk9Pic_ObsGw-S-xcEI7vpA=.0aab5db7-b801-473c-90f7-a8c6bd92364c@github.com> On Fri, 7 Nov 2025 21:40:24 GMT, Roger Riggs wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> update to use value long for folding > > src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 136: > >> 134: * >> 135: *

>> 136: * @spec https://www.unicode.org/reports/tr18/#Simple_Loose_Matches > > I'd put @spec after @return. updated according ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2529363242 From weijun at openjdk.org Sat Nov 15 01:28:08 2025 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 15 Nov 2025 01:28:08 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`. Hi @erikj79, I noticed that in our CI build the library is not built and the log shows checking for krb5 ()... no checking krb5.h usability... no checking krb5.h presence... no checking for krb5.h... no Should we require them to be present? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3535280140 From kbarrett at openjdk.org Sun Nov 16 01:10:40 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 16 Nov 2025 01:10:40 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v3] In-Reply-To: References: Message-ID: > 8369187: Add wrapper for that forbids use of global allocation and deallocation functions > > Please review this change that adds `cppstdlib/new.hpp` as a wrapper for > including ``. All existing inclusions of `` are changed to include > the new wrapper. > > In additional to including ``, this wrapper also provides deprecation > declarations to prevent the use of some facilities by HotSpot code. > > However, those deprecations need to be conditionalized to not apply to gtests, > so this change also adds a macro definition provided by the build system for > use in detecting that a header is being included by a gtest. > > Testing: mach5 tier1 Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: - Merge branch 'master' into wrap-stdlib-new - poison implicit alloc/dealloc in globalDefinitions - Merge branch 'master' into wrap-stdlib-new - further conditionalize deprecation of hardare interference sizes - add wrapper for ------------- Changes: https://git.openjdk.org/jdk/pull/28250/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28250&range=02 Stats: 207 lines in 15 files changed: 187 ins; 20 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28250.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28250/head:pull/28250 PR: https://git.openjdk.org/jdk/pull/28250 From kbarrett at openjdk.org Sun Nov 16 01:10:41 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sun, 16 Nov 2025 01:10:41 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v2] In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 05:58:25 GMT, Kim Barrett wrote: >> 8369187: Add wrapper for that forbids use of global allocation and deallocation functions >> >> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for >> including ``. All existing inclusions of `` are changed to include >> the new wrapper. >> >> In additional to including ``, this wrapper also provides deprecation >> declarations to prevent the use of some facilities by HotSpot code. >> >> However, those deprecations need to be conditionalized to not apply to gtests, >> so this change also adds a macro definition provided by the build system for >> use in detecting that a header is being included by a gtest. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge branch 'master' into wrap-stdlib-new > - further conditionalize deprecation of hardare interference sizes > - add wrapper for I added to globalDefinitions.hpp deprecating declarations for some of the implicitly declared allocation and deallocation functions. This provides better coverage for the usage poisoning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28250#issuecomment-3537249708 From yasuenag at gmail.com Mon Nov 17 02:21:34 2025 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Mon, 17 Nov 2025 11:21:34 +0900 Subject: Building OpenJDK with Visual Studio 2026 In-Reply-To: <2e60f523-5816-411f-bfd2-345d0d7a9a14@gmail.com> References: <2e60f523-5816-411f-bfd2-345d0d7a9a14@gmail.com> Message-ID: <7188c123-b281-4f86-be79-823039620a76@gmail.com> I filed it to JBS and sent PR: https://github.com/openjdk/jdk/pull/28342 I hope OpenJDK can be built with modern build toolchains. Yasumasa On 11/12/2025 9:57 PM, Yasumasa Suenaga wrote: > Hi all, > > Microsoft Visual Studio 2026 has been released, so I tried to build OpenJDK with it. > VS 2026 has not been supported yet of course, but I did it with following patch: > https://github.com/YaSuenag/jdk/commit/a96cae553573c44b6046e304caec6063d1b79c9b > > Can I contribute it? I want to know whether I can send PR now. > Let me know someone has started to work for VS 2026, or should suspend now for some reason (e.g. roadmap for build system). > > > Thanks, > > Yasumasa From ysuenaga at openjdk.org Mon Nov 17 02:28:57 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 17 Nov 2025 02:28:57 GMT Subject: RFR: 8371967: Add Visual Studio 2026 to build toolchain for Windows Message-ID: Microsoft has been published Visual Studio 2026, and it can build OpenJDK for Windows without any code changes if we add it to build toolchain. Now we should support new Visual Studio for maintainability. ------------- Commit messages: - 8371967: Add Visual Studio 2026 to build toolchain for Windows Changes: https://git.openjdk.org/jdk/pull/28342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371967 Stats: 18 lines in 3 files changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28342/head:pull/28342 PR: https://git.openjdk.org/jdk/pull/28342 From stefank at openjdk.org Mon Nov 17 09:13:43 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 17 Nov 2025 09:13:43 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v3] In-Reply-To: References: Message-ID: On Sun, 16 Nov 2025 01:10:40 GMT, Kim Barrett wrote: >> 8369187: Add wrapper for that forbids use of global allocation and deallocation functions >> >> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for >> including ``. All existing inclusions of `` are changed to include >> the new wrapper. >> >> In additional to including ``, this wrapper also provides deprecation >> declarations to prevent the use of some facilities by HotSpot code. >> >> However, those deprecations need to be conditionalized to not apply to gtests, >> so this change also adds a macro definition provided by the build system for >> use in detecting that a header is being included by a gtest. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into wrap-stdlib-new > - poison implicit alloc/dealloc in globalDefinitions > - Merge branch 'master' into wrap-stdlib-new > - further conditionalize deprecation of hardare interference sizes > - add wrapper for The last change seems reasonable to me. ------------- Marked as reviewed by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28250#pullrequestreview-3471725618 From rgangadhar at openjdk.org Mon Nov 17 13:52:17 2025 From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar) Date: Mon, 17 Nov 2025 13:52:17 GMT Subject: RFR: 8371988: Typo in JTREG_TMIEOUT_FACTOR should be corrected Message-ID: <2_H0qIMZKs5WbYGNzaNgZhoUlM3Dxf4g0bWLn5BS2Kc=.d99d784d-699d-4fc5-b55e-72145d5d11d2@github.com> WRONG: JTREG_TMIEOUT_FACTOR Correct: JTREG_TIMEOUT_FACTOR ------------- Commit messages: - 8371988: Typo in JTREG_TMIEOUT_FACTOR should be corrected - Merge branch 'openjdk:master' into 8371988-timeout - 8371988: Typo in JTREG_TMIEOUT_FACTOR should be corrected Changes: https://git.openjdk.org/jdk/pull/28351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371988 Stats: 13 lines in 2 files changed: 6 ins; 3 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28351/head:pull/28351 PR: https://git.openjdk.org/jdk/pull/28351 From rgangadhar at openjdk.org Mon Nov 17 13:52:18 2025 From: rgangadhar at openjdk.org (Ramesh Bhagavatam Gangadhar) Date: Mon, 17 Nov 2025 13:52:18 GMT Subject: RFR: 8371988: Typo in JTREG_TMIEOUT_FACTOR should be corrected In-Reply-To: <2_H0qIMZKs5WbYGNzaNgZhoUlM3Dxf4g0bWLn5BS2Kc=.d99d784d-699d-4fc5-b55e-72145d5d11d2@github.com> References: <2_H0qIMZKs5WbYGNzaNgZhoUlM3Dxf4g0bWLn5BS2Kc=.d99d784d-699d-4fc5-b55e-72145d5d11d2@github.com> Message-ID: On Mon, 17 Nov 2025 13:34:09 GMT, Ramesh Bhagavatam Gangadhar wrote: > WRONG: JTREG_TMIEOUT_FACTOR > Correct: JTREG_TIMEOUT_FACTOR Pls review this trivial change ------------- PR Comment: https://git.openjdk.org/jdk/pull/28351#issuecomment-3541920181 From jpai at openjdk.org Mon Nov 17 15:42:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 17 Nov 2025 15:42:15 GMT Subject: RFR: 8371988: Typo in JTREG_TMIEOUT_FACTOR and TMIEOUT_FACTOR should be corrected In-Reply-To: <2_H0qIMZKs5WbYGNzaNgZhoUlM3Dxf4g0bWLn5BS2Kc=.d99d784d-699d-4fc5-b55e-72145d5d11d2@github.com> References: <2_H0qIMZKs5WbYGNzaNgZhoUlM3Dxf4g0bWLn5BS2Kc=.d99d784d-699d-4fc5-b55e-72145d5d11d2@github.com> Message-ID: On Mon, 17 Nov 2025 13:34:09 GMT, Ramesh Bhagavatam Gangadhar wrote: > There are two typos in https://github.com/openjdk/jdk/blob/master/doc/testing.md > > https://github.com/openjdk/jdk/blob/master/doc/testing.md?plain=1#L292 > > Wrong: JTREG_TMIEOUT_FACTOR > Correct: JTREG_TIMEOUT_FACTOR > > > Wrong: JTREG="TMIEOUT_FACTOR... > Correct: JTREG="TIMEOUT_FACTOR... Hello Ramesh, that is actually an intentional typo. > but using the keyword format means that the `JTREG` variable is parsed and verified for correctness, so `JTREG="TMIEOUT_FACTOR=8"` would give an error, while `JTREG_TMIEOUT_FACTOR=8` would just pass unnoticed. What it's trying to explain there is that the usage of `JTREG=` style will catch and report such typos whereas using `JTREG_` will not catch that typo. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28351#issuecomment-3542518147 From xuelei at openjdk.org Mon Nov 17 18:27:26 2025 From: xuelei at openjdk.org (Xue-Lei Andrew Fan) Date: Mon, 17 Nov 2025 18:27:26 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v18] In-Reply-To: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com> References: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com> Message-ID: On Fri, 7 Nov 2025 15:25:49 GMT, Erik ?sterlund wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove -server in test for static GHA build > > Thank you for the reviews everyone! @fisk Is there any chance to backport this update to 25? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3543306783 From erikj at openjdk.org Mon Nov 17 19:02:04 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 19:02:04 GMT Subject: RFR: 8371650: Add CMakeLists.txt and compile_commands.json into .gitignore In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 02:38:48 GMT, Leonid Mesnik wrote: > Some IDE and LSP expect to find these files in the project root. > It convenient to place them in src/hotspot, so idea and vim automatically find the root for hotspot project. > > This fix just add these files and some temporary dirs in my ws into .gitignore. Shouldn't harm anyone. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28248#pullrequestreview-3474143561 From eosterlund at openjdk.org Mon Nov 17 19:02:27 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Mon, 17 Nov 2025 19:02:27 GMT Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object Caching with Any GC [v18] In-Reply-To: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com> References: <4O9v08uY1viSeMh_w821RNfKj67p74y2PqDrB8GdZCs=.e21a3d53-4a00-4f4a-99dc-589b1044d7bd@github.com> Message-ID: On Fri, 7 Nov 2025 15:25:49 GMT, Erik ?sterlund wrote: >> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove -server in test for static GHA build > > Thank you for the reviews everyone! > @fisk Is there any chance to backport this update to 25? Unfortunately, we generally do not backport JEPs. But the next LTS is just around the corner, in the grand scheme of things. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3543420953 From erikj at openjdk.org Mon Nov 17 19:04:35 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 19:04:35 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: <2UyKPJka869d7X4QtgbdbiGyYPkYnJH1DmRCpinPJMA=.6080b598-0e51-4ec6-bc72-7b0d68ef42d4@github.com> Message-ID: On Wed, 12 Nov 2025 08:59:52 GMT, Matthias Baesken wrote: >>>I think there was the concern raised previously, that without setting it for at least one lib, nobody would use/try it and the feature would 'rot' . >> >> I see, I'll run the tests for this lib then. > >> I see, I'll run the tests for this lib then. > > Great, thanks ! Please tell if it works for you and what are the size reductions you get for the lib (mostly for gcc). > Also please tell about your opinion on the configure option to enable/disable the whole 'lto on jdk native libs' . I don't think we need to disable this on a global level. For hotspot it was done because it only ever worked in specific jvm configurations. We can revisit that if we discover problems with specific toolchain versions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2535204191 From erikj at openjdk.org Mon Nov 17 19:30:04 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 19:30:04 GMT Subject: RFR: 8369188: Update link-time check for HotSpot uses of allocation and deallocation functions In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 07:07:48 GMT, Kim Barrett wrote: > Please review this update to the gcc/clang link-time check to prevent HotSpot > code from using the C++ global allocator. A number of overloads for allocation > and deallocation functions have been added since C++03 and were missing from > the list being checked for. > > Testing: mach5 tier1, GHA sanity tests (in progress) > > Locally (linux-aarch64) added uses of some of these functions and verified > they caused the expected link-time failures. Manually verified applying > c++filt to all the names in the updated list demangle to the expected function > names. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28253#pullrequestreview-3474247527 From erikj at openjdk.org Mon Nov 17 19:36:00 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 19:36:00 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: <6VJIZnsd8K7SI36fEz884BPJi7dctBZxgnBJDOSElgc=.01ec687a-5b8c-4d09-b826-0f155ef71db7@github.com> On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken wrote: >> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. >> See for example this manpage : >> https://manpages.debian.org/testing/lld-7/ld.lld-7.1 >> >> >> sizes of libjvm.so with / without -icf=all >> linux aarch64 : 25888 / 27112 K >> linux x86_64 : 27952 / 29072 K >> >> >> (for most other native libs the identical code folding has no effect, because there is nothing to fold) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Limit icf to release builds Did you consider using `--icf=safe` instead? Using `--icf==all` seems to be risky. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3543536673 From erikj at openjdk.org Mon Nov 17 19:37:43 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 19:37:43 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM Is there is a particular reason to not apply this on x64 as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3543542956 From erikj at openjdk.org Mon Nov 17 20:15:15 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 20:15:15 GMT Subject: RFR: 8371914: PNG defines in CFLAGS can cause compilation errors with external libpng In-Reply-To: References: Message-ID: On Fri, 14 Nov 2025 14:48:14 GMT, Kurt Miller wrote: > When building with external libpng the PNG defines added to CFLAGS may conflict with the installed libpng header pnglibconf.h resulting in compilation errors. For example on OpenBSD/aarch64: > > `/usr/local/include/pnglibconf.h:207:9: error: 'PNG_ARM_NEON_OPT' macro redefined [-Werror,-Wmacro-redefined]` > > This moves all `-DPNG_*` into the case where internal libpng is used. This has only been tested with the tier1 github actions so needs to be checked on Linux/ppc and AIX. I think this looks ok, but someone from client should weigh in too. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28324#pullrequestreview-3474397386 From bpb at openjdk.org Mon Nov 17 20:26:57 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 17 Nov 2025 20:26:57 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v18] 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 18 commits: - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - ... and 8 more: https://git.openjdk.org/jdk/compare/9ec773ad...75555455 ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=17 Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 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 erikj at openjdk.org Mon Nov 17 20:37:08 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 20:37:08 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality In-Reply-To: References: Message-ID: On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Is there a particular reason for build.sh in the tests or are you just not familiar with how native test code gets automatically compiled by the makefiles based on file naming conventions? In short, any file `lib*.c[pp]` will get compiled into a native library (and exe*.c[pp] into an executable). You can define any special flags or platform include/exclude in `make/test/JtregNativeJdk.gmk`. > Hi @erikj79, I noticed that in our CI build the library is not built and the log shows > > ``` > checking for krb5 ()... no > checking krb5.h usability... no > checking krb5.h presence... no > checking for krb5.h... no > ``` > > How can we require them to be present? Is this intended to be a required dependency for OpenJDK or are you referring to how we would enable this feature and dependency for Oracle builds? If the latter, they would need to be part of the devkit that we use. So the first step would be to modify the devkit creation makefiles for Linux in `make/devkit/...`, then create a new devkit, verify and deploy internally. You will also need to verify that libkrb5 is reasonably stable and compatible across versions, since we only build one JDK distribution per architecture for Linux. We use a sysroot from the oldest Linux distribution we support, so you would need to verify that linking against libkrb5 in that sysroot/devkit results in a JDK that is still runtime compatible with all the Linux versions we support. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3543727972 From erikj at openjdk.org Mon Nov 17 20:43:13 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 20:43:13 GMT Subject: RFR: 8371967: Add Visual Studio 2026 to build toolchain for Windows In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 02:20:23 GMT, Yasumasa Suenaga wrote: > Microsoft has been published Visual Studio 2026, and it can build OpenJDK for Windows without any code changes if we add it to build toolchain. > > Now we should support new Visual Studio for maintainability. Looks good to me, as long as it works. I don't have the ability to verify myself so will have to take your word for it. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28342#pullrequestreview-3474481346 From erikj at openjdk.org Mon Nov 17 20:45:04 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 17 Nov 2025 20:45:04 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v3] In-Reply-To: References: Message-ID: On Sun, 16 Nov 2025 01:10:40 GMT, Kim Barrett wrote: >> 8369187: Add wrapper for that forbids use of global allocation and deallocation functions >> >> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for >> including ``. All existing inclusions of `` are changed to include >> the new wrapper. >> >> In additional to including ``, this wrapper also provides deprecation >> declarations to prevent the use of some facilities by HotSpot code. >> >> However, those deprecations need to be conditionalized to not apply to gtests, >> so this change also adds a macro definition provided by the build system for >> use in detecting that a header is being included by a gtest. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into wrap-stdlib-new > - poison implicit alloc/dealloc in globalDefinitions > - Merge branch 'master' into wrap-stdlib-new > - further conditionalize deprecation of hardare interference sizes > - add wrapper for Build change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28250#pullrequestreview-3474488290 From kbarrett at openjdk.org Mon Nov 17 20:56:12 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 17 Nov 2025 20:56:12 GMT Subject: RFR: 8369188: Update link-time check for HotSpot uses of allocation and deallocation functions In-Reply-To: References: Message-ID: <9IHidXHx_Zwjf5FqbMNf3I5i1SwvKRszAU5zXR69VNM=.618b72f7-f1d8-48ac-94a9-0dc20b89306e@github.com> On Wed, 12 Nov 2025 13:46:53 GMT, Julian Waters wrote: >> Please review this update to the gcc/clang link-time check to prevent HotSpot >> code from using the C++ global allocator. A number of overloads for allocation >> and deallocation functions have been added since C++03 and were missing from >> the list being checked for. >> >> Testing: mach5 tier1, GHA sanity tests (in progress) >> >> Locally (linux-aarch64) added uses of some of these functions and verified >> they caused the expected link-time failures. Manually verified applying >> c++filt to all the names in the updated list demangle to the expected function >> names. > > Looks good to me Thanks for reviews @TheShermanTanker and @erikj79 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28253#issuecomment-3543779339 From kbarrett at openjdk.org Mon Nov 17 20:56:13 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 17 Nov 2025 20:56:13 GMT Subject: Integrated: 8369188: Update link-time check for HotSpot uses of allocation and deallocation functions In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 07:07:48 GMT, Kim Barrett wrote: > Please review this update to the gcc/clang link-time check to prevent HotSpot > code from using the C++ global allocator. A number of overloads for allocation > and deallocation functions have been added since C++03 and were missing from > the list being checked for. > > Testing: mach5 tier1, GHA sanity tests (in progress) > > Locally (linux-aarch64) added uses of some of these functions and verified > they caused the expected link-time failures. Manually verified applying > c++filt to all the names in the updated list demangle to the expected function > names. This pull request has now been integrated. Changeset: 6c09529c Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/6c09529cd637a34c1ffc42a5feb71e8646be4237 Stats: 34 lines in 1 file changed: 32 ins; 0 del; 2 mod 8369188: Update link-time check for HotSpot uses of allocation and deallocation functions Reviewed-by: jwaters, erikj ------------- PR: https://git.openjdk.org/jdk/pull/28253 From lmesnik at openjdk.org Mon Nov 17 21:03:25 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 17 Nov 2025 21:03:25 GMT Subject: Integrated: 8371650: Add CMakeLists.txt and compile_commands.json into .gitignore In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 02:38:48 GMT, Leonid Mesnik wrote: > Some IDE and LSP expect to find these files in the project root. > It convenient to place them in src/hotspot, so idea and vim automatically find the root for hotspot project. > > This fix just add these files and some temporary dirs in my ws into .gitignore. Shouldn't harm anyone. This pull request has now been integrated. Changeset: e5f63326 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/e5f63326100384d2c2be8c916423e1f120b595d3 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8371650: Add CMakeLists.txt and compile_commands.json into .gitignore Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/28248 From ysuenaga at openjdk.org Mon Nov 17 23:54:09 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Mon, 17 Nov 2025 23:54:09 GMT Subject: RFR: 8371967: Add Visual Studio 2026 to build toolchain for Windows In-Reply-To: References: Message-ID: <0XI9ImO6mSl_R6HG2xD1OVtkiM85O3y2siSNJWRF9Fc=.ce82a5b6-52e9-42a9-bc9b-0ad25f15727d@github.com> On Mon, 17 Nov 2025 20:40:10 GMT, Erik Joelsson wrote: >> Microsoft has been published Visual Studio 2026, and it can build OpenJDK for Windows without any code changes if we add it to build toolchain. >> >> Now we should support new Visual Studio for maintainability. > > Looks good to me, as long as it works. I don't have the ability to verify myself so will have to take your word for it. Thanks @erikj79 for your review! I tested this change with VS 2026 Community Edition on WSL1 (Fedora 42) on Windows 11 25H2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28342#issuecomment-3544355349 From weijun at openjdk.org Tue Nov 18 04:52:16 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 18 Nov 2025 04:52:16 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: Message-ID: <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com> On Thu, 13 Nov 2025 11:02:21 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with three additional commits since the last revision: > > - Small doc fix > - Attend to @wangweij's code review comments - in particular a large clean-up of the test helper and the output it creates > - Attend to remaining comments from @smemery I am thinking this should be a required dependency. Otherwise, the JDK build will vary depending on the machine used. I don?t believe we?ve ever done this before (unless user explicitly specifies configure options), right? @nrhall, a related question: what if the library is available at build time but not at runtime? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3545020829 From mbaesken at openjdk.org Tue Nov 18 08:16:17 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Nov 2025 08:16:17 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: <6VJIZnsd8K7SI36fEz884BPJi7dctBZxgnBJDOSElgc=.01ec687a-5b8c-4d09-b826-0f155ef71db7@github.com> References: <6VJIZnsd8K7SI36fEz884BPJi7dctBZxgnBJDOSElgc=.01ec687a-5b8c-4d09-b826-0f155ef71db7@github.com> Message-ID: On Mon, 17 Nov 2025 19:32:55 GMT, Erik Joelsson wrote: > Did you consider using `--icf=safe` instead? Using `--icf==all` seems to be risky. I tried this too, it works but the binaries are a bit larger with this setting, but I have no detailed values. Regarding 'risky' I did not see any test issues with the flag added in our CI . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3546097810 From mbaesken at openjdk.org Tue Nov 18 08:58:17 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Nov 2025 08:58:17 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Mon, 17 Nov 2025 19:34:55 GMT, Erik Joelsson wrote: > Is there is a particular reason to not apply this on x64 as well? On macOS x86_64 I saw in our CI those tests failing when enabling the dead_strip feature serviceability/sa/ClhsdbCDSCore.java serviceability/sa/ClhsdbFindPC.jav serviceability/sa/ClhsdbPstack.java (and macOS on Intel is not that interesting any more these days) For macOS aarch64, the tests in our CI were fine but I see some failures in the GHA in the serviceability area. finding class loader instances ..java.lang.InternalError: Metadata does not appear to be polymorphic at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223) at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78) at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:102) at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) Have to check why I do not see those issues in our test infra. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3546278266 From duke at openjdk.org Tue Nov 18 12:21:09 2025 From: duke at openjdk.org (Nick Hall) Date: Tue, 18 Nov 2025 12:21:09 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v13] In-Reply-To: References: Message-ID: > _Purpose_ > > This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. > > _Rationale_ > > Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. > > The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). > > Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. > > _Implementation Detail_ > > Note that there were multiple possible ways of doing this: > > 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. > > 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. > > 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. > > I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensate for this. > > Interested to hear if anyone else... Nick Hall has updated the pull request incrementally with one additional commit since the last revision: Clean up jtreg run/compile directives, attend to other review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28075/files - new: https://git.openjdk.org/jdk/pull/28075/files/d7ea6c9e..ed56092b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28075&range=11-12 Stats: 29 lines in 2 files changed: 0 ins; 18 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28075.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28075/head:pull/28075 PR: https://git.openjdk.org/jdk/pull/28075 From duke at openjdk.org Tue Nov 18 12:21:10 2025 From: duke at openjdk.org (Nick Hall) Date: Tue, 18 Nov 2025 12:21:10 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com> References: <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com> Message-ID: On Tue, 18 Nov 2025 04:49:35 GMT, Weijun Wang wrote: > I am thinking this should be a required dependency. Otherwise, the JDK build will vary depending on the machine used. I don?t believe we?ve ever done this before (unless user explicitly specifies configure options), right? > > @nrhall, a related question: what if the library is available at build time but not at runtime? If libkrb5 available at build time, it will build the new JNI library/test etc as expected; if libkrb5 is then not available at runtime, the library will fail to load silently (once, and then will not be retried) - this was actually already part of the code, so I imagine this case has happened before somewhere already - see Credentials.java L446: if (!alreadyTried) { // See if there's any native code to load try { ensureLoaded(); } catch (Exception e) { if (DEBUG != null) { DEBUG.println("Can not load native ccache library"); e.printStackTrace(); } alreadyTried = true; } } I will say that libkrb5 is largely pretty stable (it's really old code with few features being added), though I'm not sure what range is required to be supported here in terms of operating system builds? Worst case though, any incompatibility will just result in this code not being used, although as it'd be a silent failure without debug flags, that's perhaps not ideal (but has always been the case, even before this change). @wangweij I've attended to your code review feedback above (and cleaned up a few other bits of the jtreg directives that weren't required). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3547350870 PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3547354335 From duke at openjdk.org Tue Nov 18 13:20:42 2025 From: duke at openjdk.org (Nick Hall) Date: Tue, 18 Nov 2025 13:20:42 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v12] In-Reply-To: References: <25c1wupthdBJWf9lLmRnZG_Z4sVhwF3iqtDo42DX26w=.152e78c9-51b5-4b6d-b54a-44f126921d5f@github.com> Message-ID: On Tue, 18 Nov 2025 12:15:38 GMT, Nick Hall wrote: > I will say that libkrb5 is largely pretty stable (it's really old code with few features being added), though I'm not sure what range is required to be supported here in terms of operating system builds? Worst case though, any incompatibility will just result in this code not being used, although as it'd be a silent failure without debug flags, that's perhaps not ideal (but has always been the case, even before this change). Two data points, but the JVM/krb5 library/jtreg test compiled on RHEL8 works on Ubuntu 24.04, and these two are reasonably far apart: - RHEL8 glibc 2.28 kernel 4.18.0 krb5 1.18 - Ubuntu 24.04 glibc 2.39 kernel 6.8.0 krb5 1.20 Obviously the reverse doesn't work, but that's to be expected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3547609210 From erikj at openjdk.org Tue Nov 18 14:03:07 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Nov 2025 14:03:07 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: <6VJIZnsd8K7SI36fEz884BPJi7dctBZxgnBJDOSElgc=.01ec687a-5b8c-4d09-b826-0f155ef71db7@github.com> Message-ID: On Tue, 18 Nov 2025 08:13:52 GMT, Matthias Baesken wrote: > > Did you consider using `--icf=safe` instead? Using `--icf==all` seems to be risky. > > I tried this too, it works but the binaries are a bit larger with this setting, but I have no detailed values. Regarding 'risky' I did not see any test issues with the flag added in our CI . I would like input from someone in Hotspot regarding implications on debugging and if the changes to memory layout could cause any issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3547771623 From erikj at openjdk.org Tue Nov 18 14:08:15 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Nov 2025 14:08:15 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Tue, 18 Nov 2025 08:55:16 GMT, Matthias Baesken wrote: > > Is there is a particular reason to not apply this on x64 as well? > > On macOS x86_64 I saw in our CI those tests failing when enabling the dead_strip feature serviceability/sa/ClhsdbCDSCore.java serviceability/sa/ClhsdbFindPC.jav serviceability/sa/ClhsdbPstack.java That information should at least be stated in the bug for future reference on why this decision was made. > For macOS aarch64, the tests in our CI were fine but I see some failures in the GHA in the serviceability area. > > ``` > finding class loader instances ..java.lang.InternalError: Metadata does not appear to be polymorphic > at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) > at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:102) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > ``` Adding serviceability label as this is affecting their tests. I have a vague memory of some seemingly dead code being necessary for certain sa functionality. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3547789577 From mbaesken at openjdk.org Tue Nov 18 14:38:17 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Nov 2025 14:38:17 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Tue, 18 Nov 2025 14:05:32 GMT, Erik Joelsson wrote: > I have a vague memory of some seemingly dead code being necessary for certain sa functionality. Yeah I remember too, We noticed similar issues when using the lto configure flag on libjvm with gcc (other platform and switch but similar issues). Is there a way to attribute such 'dead' functions with e.g. an attribute to pragma or something similar to avoid removal of those ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3547901166 From mbaesken at openjdk.org Tue Nov 18 14:42:19 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Nov 2025 14:42:19 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM The was a bit of discussion on serviceability-dev some years ago about that lto on libjvm issue and the serviceability errors and Magnus commented 'We used to have LTO enabled on the old, closed-source Oracle arm-32 builds. There is still a "link-time-opt" JVM feature present; afaik it still works and adds the -flto flag. The main drawback of this is the *extremely* long link times of libjvm.so. I don't think servicability was ever supported for that platform, so I'm not surprised this does not work. ' Probably the dead-strip feature runs into similar issues. I commented back then 'The serviceability tests like serviceability/sa seems to rely heavily on the "normal" structure of libjvm.so (from what I understand e.g. in LinuxVtblAccess it is attempted to access internal symbols like _ZTV ).' ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3547920976 From ysuenaga at openjdk.org Tue Nov 18 14:48:16 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Tue, 18 Nov 2025 14:48:16 GMT Subject: Integrated: 8371967: Add Visual Studio 2026 to build toolchain for Windows In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 02:20:23 GMT, Yasumasa Suenaga wrote: > Microsoft has been published Visual Studio 2026, and it can build OpenJDK for Windows without any code changes if we add it to build toolchain. > > Now we should support new Visual Studio for maintainability. This pull request has now been integrated. Changeset: dcba014a Author: Yasumasa Suenaga URL: https://git.openjdk.org/jdk/commit/dcba014ad56eae753c25c579fb30bb8ecfab69af Stats: 18 lines in 3 files changed: 15 ins; 0 del; 3 mod 8371967: Add Visual Studio 2026 to build toolchain for Windows Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/28342 From mbaesken at openjdk.org Tue Nov 18 15:50:34 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 18 Nov 2025 15:50:34 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: <6VJIZnsd8K7SI36fEz884BPJi7dctBZxgnBJDOSElgc=.01ec687a-5b8c-4d09-b826-0f155ef71db7@github.com> Message-ID: On Tue, 18 Nov 2025 14:00:33 GMT, Erik Joelsson wrote: > I would like input from someone in Hotspot regarding implications on debugging and if the changes to memory layout could cause any issues. Makes of course sense to ask the hotspot developers too. Implications on debugging would mean that you potentially see the 'folded' method/function name in the debugger. But that should occur too with the opt:icf,8 setting on Windows that is used for some years. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3548301308 From liach at openjdk.org Tue Nov 18 16:41:32 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 18 Nov 2025 16:41:32 GMT Subject: RFR: 8366094: Sealed graph for nested types creates broken links [v3] In-Reply-To: <-k6Pl4zkJCrLubFltPYXsWTUVMql0gszWG-5JRgQwe4=.045b6320-07c3-4c50-8580-8a158bb00af5@github.com> References: <-k6Pl4zkJCrLubFltPYXsWTUVMql0gszWG-5JRgQwe4=.045b6320-07c3-4c50-8580-8a158bb00af5@github.com> Message-ID: On Fri, 14 Nov 2025 10:07:07 GMT, Hannes Walln?fer wrote: >> Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs must have a matching `../` for each enclosing type. >> >> Fixed graphs for some nested sealed types: >> - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html) >> - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html) >> - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) >> >> There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828). > > Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to explain SVG naming scheme These links are weird right now. This fix is good, we can fix the svg file locations later. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28134#pullrequestreview-3478734910 From hannesw at openjdk.org Tue Nov 18 16:55:51 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 18 Nov 2025 16:55:51 GMT Subject: Integrated: 8366094: Sealed graph for nested types creates broken links In-Reply-To: References: Message-ID: <_ix8Qq2G8v6Dh2FNxTPND7wx-ZEaEFX71SklDJ2IVWk=.295f4376-f494-49e5-b5eb-6fa01220e955@github.com> On Tue, 4 Nov 2025 15:28:27 GMT, Hannes Walln?fer wrote: > Please review a change to fix broken links in sealed type hierarchy graphs for nested types. The problem is that SVG files for nested types use the names of enclosing types as parent directories. Therefore, links from nested type SVGs must have a matching `../` for each enclosing type. > > Fixed graphs for some nested sealed types: > - [ClassFile.Option](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/ClassFile.Option.html) > - [Signature.RefTypeSig](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/Signature.RefTypeSig.html) > - [TypeAnnotation.TargetInfo](https://cr.openjdk.org/~hannesw/8366094/api.00/java.base/java/lang/classfile/TypeAnnotation.TargetInfo.html) > > There is currently no test coverage for the sealed graph taglet. I tested the fix manually, a test should be added with [JDK-8366828](https://bugs.openjdk.org/browse/JDK-8366828). This pull request has now been integrated. Changeset: ac6f5e96 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/ac6f5e96512a7f003ac536611c53f2564ea912a6 Stats: 7 lines in 1 file changed: 2 ins; 2 del; 3 mod 8366094: Sealed graph for nested types creates broken links Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28134 From weijun at openjdk.org Tue Nov 18 17:33:39 2025 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 18 Nov 2025 17:33:39 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v13] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Clean up jtreg run/compile directives, attend to other review comments `UnsatisfiedLinkError` is not an `Exception`. It's just a `Throwable`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3548783827 From aph at openjdk.org Tue Nov 18 18:00:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Tue, 18 Nov 2025 18:00:10 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM Surely you're going to use features that are provided for debugging. They aren't called from anywhere, but they are used when debugging HotSpot. And you still need them even if you're not using a debug build. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3548890774 From duke at openjdk.org Tue Nov 18 18:51:05 2025 From: duke at openjdk.org (Nick Hall) Date: Tue, 18 Nov 2025 18:51:05 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v13] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 17:31:04 GMT, Weijun Wang wrote: > `UnsatisfiedLinkError` is not an `Exception`. It's just a `Throwable`. Good point. I wonder what the intent of that exception handling code is, then. I assumed it was to silently fall back to using the pure Java code in the event a library was un-loadable / not present, etc. In this particular case, it's almost essential that this happens, because otherwise a JDK with this feature compiled in and distributed to a machine without libkrb5 installed would basically be unable to use anything that called the `Credentials` class methods. Looking at the code further: `ensureLoaded()` calls only `System.loadLibrary()`, which only throws the following checked exceptions: SecurityException UnsatisfiedLinkError NullPointerException Of those, the libname is always a static string, so that just leaves the first two (or another `RuntimeException`). Either of those will yield an un-loadable library, but the first will be swallowed. Does that mean the code above should also catch the `UnsatisfiedLinkError`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3549093006 From duke at openjdk.org Tue Nov 18 18:59:07 2025 From: duke at openjdk.org (Nick Hall) Date: Tue, 18 Nov 2025 18:59:07 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v13] In-Reply-To: References: Message-ID: <-ZOtR8BhuO9VihBuWdAi_Anygy_imtkjr9AwqUgdQ0k=.56f35e65-6cec-45bd-993a-87ff1af9599e@github.com> On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Clean up jtreg run/compile directives, attend to other review comments For what it's worth, here's how this looks using KCM on a host... ...with libkrb5 krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:30:45.208]: Acquire TGT from Cache krb5loginmodule[0x3|main|Krb5LoginModule.java:678|2025-11-18 13:30:45.252]: Principal is user-redacted at REALM.REDACTED krb5loginmodule[0x3|main|Krb5LoginModule.java:1140|2025-11-18 13:30:45.272]: Commit Succeeded krb5loginmodule[0x3|main|Krb5LoginModule.java:1190|2025-11-18 13:30:45.273]: [Krb5LoginModule]: Entering logout krb5loginmodule[0x3|main|Krb5LoginModule.java:1218|2025-11-18 13:30:45.273]: [Krb5LoginModule]: logged out Subject ...without libkrb5: krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:34:13.604]: Acquire TGT from Cache Exception in thread "main" java.lang.UnsatisfiedLinkError: /path/redacted/jdk/build/linux-x86_64-server-release/jdk/lib/liblinuxkrb5.so: libkrb5.so.3: cannot open shared object file: No such file or directory at java.base/jdk.internal.loader.NativeLibraries.load(Native Method) at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:326) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:187) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:129) at java.base/jdk.internal.loader.NativeLibraries.findFromPaths(NativeLibraries.java:254) at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:239) at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2315) at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:822) at java.base/java.lang.System.loadLibrary(System.java:1685) at java.security.jgss/sun.security.krb5.Credentials.ensureLoaded(Credentials.java:535) at java.security.jgss/sun.security.krb5.Credentials.acquireDefaultCreds(Credentials.java:449) at java.security.jgss/sun.security.krb5.Credentials.acquireTGTFromCache(Credentials.java:335) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:649) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:601) at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:603) at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:460) at RunWhoAmI.main(RunWhoAmI.java:22) ...without libkrb5, but with a small patch to also catch `UnsatisfiedLinkError`: krb5loginmodule[0x3|main|Krb5LoginModule.java:647|2025-11-18 13:52:09.045]: Acquire TGT from Cache krb5loginmodule[0x3|main|Krb5LoginModule.java:678|2025-11-18 13:52:09.053]: Principal is null krb5loginmodule[0x3|main|Krb5LoginModule.java:681|2025-11-18 13:52:09.053]: null credentials from Ticket Cache krb5loginmodule[0x3|main|Krb5LoginModule.java:608|2025-11-18 13:52:09.054]: [Krb5LoginModule] authentication failed Unable to obtain Principal Name for authentication Login failed javax.security.auth.login.LoginException: Unable to obtain Principal Name for authentication at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.promptForName(Krb5LoginModule.java:816) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication(Krb5LoginModule.java:693) at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:601) at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:603) at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:460) at RunWhoAmI.main(RunWhoAmI.java:22) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3549110005 From cjplummer at openjdk.org Tue Nov 18 21:47:05 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 18 Nov 2025 21:47:05 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM SA is throwing an exception on the following: ` Klass classLoaderKlass = vm.getSystemDictionary().getClassLoaderKlass();` This looks to be the first thing it is doing that involves looking up a hotspot symbol. Possibly the issue is with symbols in general being stripped, or maybe just this one was. The fact that only 3 tests failed makes me think it is some very selective dead stripping of symbols that is the problem. Most SA functionality does not use SystemDictionary().getClassLoaderKlass(), so if just this one symbol was missing, that would explain why for the most part SA is working. On the assumption that it is just this one symbol, Hotspot declares an array of InstanceKlass* for some critical classes: InstanceKlass* vmClasses::_klasses[static_cast(vmClassID::LIMIT)] = { nullptr /*, nullptr...*/ }; In SA, the failed SystemDictionary.initialize() part of the stacktrace shows an attempt to access this array for the ClassLoader InstanceKlass* ` classLoaderKlassField = type.getAddressField(VM_CLASS_AT("ClassLoader_klass"));` private static String VM_CLASS_AT(String name) { return "_klasses[static_cast(" + VM_CLASS_ID(name) + ")]"; } And in vmStructs we have: ` static_field(vmClasses, VM_CLASS_AT(ClassLoader_klass), InstanceKlass*) ` I think this vmStructs static field is getting dead stripped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3549555596 From mdonovan at openjdk.org Tue Nov 18 21:56:36 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Tue, 18 Nov 2025 21:56:36 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests Message-ID: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: make test JTREG=MANUAL=true TEST=... I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. ------------- Commit messages: - 8247690: RunTest does not support running of JTREG manual tests Changes: https://git.openjdk.org/jdk/pull/28381/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8247690 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28381/head:pull/28381 PR: https://git.openjdk.org/jdk/pull/28381 From erikj at openjdk.org Tue Nov 18 22:03:31 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 18 Nov 2025 22:03:31 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests In-Reply-To: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Tue, 18 Nov 2025 20:29:50 GMT, Matthew Donovan wrote: > This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: > > > make test JTREG=MANUAL=true TEST=... > > > I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. I think this looks ok. Please update doc/testing.[md|html] with documentation describing this new option. ------------- PR Review: https://git.openjdk.org/jdk/pull/28381#pullrequestreview-3479840262 From cjplummer at openjdk.org Tue Nov 18 22:27:03 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 18 Nov 2025 22:27:03 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: <2CNk3Ufuu-ZmSz5qfhB4jKCP4H7VGDP0DqA_xAsEKic=.50f3f7c7-38db-4a94-a607-82837685e5d2@github.com> On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM Sorry, I think I went somewhat astray in my comments above. I think `classLoaderKlassField` is being initialized. It's value (an address) is then passed to instantiateWrapperFor(): public static InstanceKlass getClassLoaderKlass() { return (InstanceKlass)Metadata.instantiateWrapperFor(classLoaderKlassField.getValue()); } instantiateWrapperFor() is failing. If you look at the stack trace (and the accompanying code), it appears that it has failed to lookup the base type, which is Metadata. There probably are no instances of Metadata allocated, just instances of subclasses, so possibly the Metadata vtbl has been dead stripped, and SA needs it. However, I would think this would result in mass failures since we call Metadata.instantiateWrapperFor() all over the place. If you want to attempt a fix, have hotspot allocate a Metadata instance somewhere and keep a reference to it. That should prevent the Metadata vtbl from being dead stripped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3549682521 From serb at openjdk.org Tue Nov 18 23:39:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 18 Nov 2025 23:39:32 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM As usual, maybe it is possible to split this patch between hotspot and the libraries? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3549889174 From cjplummer at openjdk.org Wed Nov 19 02:31:51 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Nov 2025 02:31:51 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com> On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM I reproduced the SA issues locally. Not surprisingly almost every SA test failed (I'm not sure why only 3 were listed above). They seemed to all fail trying to get a vtable for a hotspot type. The tests that didn't failed were doing mundane things like testing attaching, hotspot flags, and clhsdb history, but not doing anything with hotspot objects, or at least not with hotspot metadata. I was able to confirm the problem is with the Metadata vtable missing. I fixed it by allocating a Metadata instance and assigning it to a global. However, in order to get this to compile I had make Metadata no longer be abstract. All tests passed after I did this. I'm not sure how viable a solution this is. The hotspot team will probably object to the Metadata changes. Maybe there is some other way to cause a reference to the Metadata vtable so it is not dead stripped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3550388831 From syan at openjdk.org Wed Nov 19 05:55:17 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 19 Nov 2025 05:55:17 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests In-Reply-To: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Tue, 18 Nov 2025 20:29:50 GMT, Matthew Donovan wrote: > This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: > > > make test JTREG=MANUAL=true TEST=... > > > I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. I think it's no need to distinguish manual tests and automatic tests. Just remove '-automatic' will make the original make command can run all the jtreg tests except the test has mark as '@ignore' ------------- PR Review: https://git.openjdk.org/jdk/pull/28381#pullrequestreview-3480926642 From mbaesken at openjdk.org Wed Nov 19 08:32:25 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Nov 2025 08:32:25 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com> Message-ID: On Wed, 19 Nov 2025 02:29:31 GMT, Chris Plummer wrote: > Maybe there is some other way to cause a reference to the Metadata vtable so it is not dead stripped. Would be good to have a fix people agree on, because we already saw the issue with lto enabled for Hotspot (see my comment above). So it is not only an issue related to the dead_strip flag. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3551410166 From mdonovan at openjdk.org Wed Nov 19 12:52:02 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 19 Nov 2025 12:52:02 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v2] In-Reply-To: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: > This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: > > > make test JTREG=MANUAL=true TEST=... > > > I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: removed manual/automatic flag entirely ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28381/files - new: https://git.openjdk.org/jdk/pull/28381/files/6e1a5a9a..1cfa515d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28381/head:pull/28381 PR: https://git.openjdk.org/jdk/pull/28381 From mdonovan at openjdk.org Wed Nov 19 13:01:08 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 19 Nov 2025 13:01:08 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v2] In-Reply-To: References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Wed, 19 Nov 2025 05:53:00 GMT, SendaoYan wrote: > Seems that it's no need to distinguish manual tests and automatic tests. Just remove '-automatic' will make the original make command can run all the jtreg tests except the test has mark as '@ignore' I reverted my change and removed the '-automatic' flag. However, I can see an argument for having the flag. When specifying a test directory (instead of a specific test) the flag will only run the automatic or manual tests. That can be useful if you have to do manual test verification. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28381#issuecomment-3552566823 From mbaesken at openjdk.org Wed Nov 19 13:07:28 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Nov 2025 13:07:28 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Tue, 18 Nov 2025 23:36:10 GMT, Sergey Bylokhov wrote: > As usual, maybe it is possible to split this patch between hotspot and the libraries? For sure we can do this. But as listed above, we only see for a few jdk native libs a good size benefit when using this additional flag. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552594695 From mbaesken at openjdk.org Wed Nov 19 13:11:29 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Nov 2025 13:11:29 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Tue, 18 Nov 2025 08:55:16 GMT, Matthias Baesken wrote: > > Is there is a particular reason to not apply this on x64 as well? > > On macOS x86_64 I saw in our CI those tests failing when enabling the dead_strip feature serviceability/sa/ClhsdbCDSCore.java serviceability/sa/ClhsdbFindPC.jav serviceability/sa/ClhsdbPstack.java > > (and macOS on Intel is not that interesting any more these days) > > For macOS aarch64, the tests in our CI were fine but I see some failures in the GHA in the serviceability area. > > ``` > finding class loader instances ..java.lang.InternalError: Metadata does not appear to be polymorphic > at jdk.hotspot.agent/sun.jvm.hotspot.types.basic.BasicTypeDataBase.findDynamicTypeForAddress(BasicTypeDataBase.java:223) > at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualBaseConstructor.instantiateWrapperFor(VirtualBaseConstructor.java:104) > at jdk.hotspot.agent/sun.jvm.hotspot.oops.Metadata.instantiateWrapperFor(Metadata.java:78) > at jdk.hotspot.agent/sun.jvm.hotspot.memory.SystemDictionary.getClassLoaderKlass(SystemDictionary.java:102) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.printClassLoaderStatistics(ClassLoaderStats.java:93) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.ClassLoaderStats.run(ClassLoaderStats.java:78) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:121) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134) > at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344) > at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507) > ``` > > Have to check why I do not see those issues in our test infra. Okay I checked why this is the case. In our internal test setup we see some serviceability/sa - tests skipped because of 'SA Attach not expected to work. Insufficient privileges' . This can happen in some test setups especially on macOS but is not very helpful to test the influence of the dead_strip flag on the sa tests . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552605391 From aph at openjdk.org Wed Nov 19 13:19:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 19 Nov 2025 13:19:16 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM I remember s390 used to strip unneeded stuff, and it was very hard to debug anything. Please think about whether you need to do this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552643306 From syan at openjdk.org Wed Nov 19 13:21:22 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 19 Nov 2025 13:21:22 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v2] In-Reply-To: References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Wed, 19 Nov 2025 12:58:30 GMT, Matthew Donovan wrote: > However, I can see an argument for having the flag. When specifying a test directory (instead of a specific test) the flag will only run the automatic or manual tests. That can be useful if you have to do manual test verification. Do you mean run all the manual tests for the specific directory. Maybe pass parameter `JTREG="OPTIONS=-m"` can make this thing work, such as run all the manual tests in test/jdk directory. make test TEST=test/jdk/ JTREG="OPTIONS=-m" ------------- PR Comment: https://git.openjdk.org/jdk/pull/28381#issuecomment-3552653997 From mbaesken at openjdk.org Wed Nov 19 13:26:29 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Nov 2025 13:26:29 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Wed, 19 Nov 2025 13:14:33 GMT, Andrew Haley wrote: > I remember s390 used to strip unneeded stuff, and it was very hard to debug anything. What exactly was hard to debug? Did you use (fast)debug or product binaries ? I do not remember issues like this on s390 but I can ask my (ex)colleagues who dealt more with s390 . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3552676735 From erikj at openjdk.org Wed Nov 19 13:48:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 19 Nov 2025 13:48:16 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v2] In-Reply-To: References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Wed, 19 Nov 2025 12:58:30 GMT, Matthew Donovan wrote: > Seems that it's no need to distinguish manual tests and automatic tests. Just remove '-automatic' will make the original make command can run all the jtreg tests except the test has mark as '@ignore' What makes you say this? We have tons of tests with the `/manual` option specified. Those are currently filtered out when running tests through the makefiles. Removing `-automatic` will make those suddenly run everywhere. The original patch made sense, this does not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28381#issuecomment-3552787302 From syan at openjdk.org Wed Nov 19 14:19:31 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 19 Nov 2025 14:19:31 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v2] In-Reply-To: References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Wed, 19 Nov 2025 13:44:08 GMT, Erik Joelsson wrote: > > Seems that it's no need to distinguish manual tests and automatic tests. Just remove '-automatic' will make the original make command can run all the jtreg tests except the test has mark as '@ignore' > > What makes you say this? We have tons of tests with the `/manual` option specified. Those are currently filtered out when running tests through the makefiles. Removing `-automatic` will make those suddenly run everywhere. The original patch made sense, this does not. I think you are right, we are relay on the default '-automatic' option to exclude the '/manual' tests, especial the CI? It's not a good idea to change the long history habit ------------- PR Comment: https://git.openjdk.org/jdk/pull/28381#issuecomment-3552949541 From mbaesken at openjdk.org Wed Nov 19 15:06:46 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Nov 2025 15:06:46 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM Btw on Linux s390x it is the `linktime-gc` , but from what I see this can be disabled by configure if you don't like it https://github.com/openjdk/jdk/blob/0bff5f3dbe69ab2a59db771af1020b04c0132954/make/autoconf/jdk-options.m4#L112 https://github.com/openjdk/jdk/blob/0bff5f3dbe69ab2a59db771af1020b04c0132954/make/autoconf/flags-ldflags.m4#L55 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553211601 From weijun at openjdk.org Wed Nov 19 15:19:09 2025 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 19 Nov 2025 15:19:09 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v13] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 18:48:22 GMT, Nick Hall wrote: > Does that mean the code above should also catch the `UnsatisfiedLinkError`? If we make `libkrb5` a required dependency and make sure your new native code is always compiled into JDK, this is a real error and we should fail loudly. Otherwise, we need to fallback to pure Java. I guess this is also the reason why it was not caught before. I still think it should be a required dependency. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3553277926 From mbaesken at openjdk.org Wed Nov 19 15:22:45 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Nov 2025 15:22:45 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com> Message-ID: On Wed, 19 Nov 2025 02:29:31 GMT, Chris Plummer wrote: > I reproduced the SA issues locally. Not surprisingly almost every SA test failed (I'm not sure why only 3 were listed above). They seemed to all fail trying to get a vtable for a hotspot type. The tests that didn't failed were doing mundane things like testing attaching, hotspot flags, and clhsdb history, but not doing anything with hotspot objects, or at least not with hotspot metadata. > > I was able to confirm the problem is with the Metadata vtable missing. I fixed it by allocating a Metadata instance and assigning it to a global. However, in order to get this to compile I had make Metadata no longer be abstract. All tests passed after I did this. I'm not sure how viable a solution this is. The hotspot team will probably object to the Metadata changes. Maybe there is some other way to cause a reference to the Metadata vtable so it is not dead stripped. There seem to be attributes for this kind of use case in clang, e.g. retain https://reviews.llvm.org/D97447 https://clang.llvm.org/docs/AttributeReference.html#retain Should we add this to 'class Metadata' ? If we can do it with attributes or something similar (and without changing lots of code locations) it sounds better to me than adjusting the coding. 'Pseudo dead' stuff that is used from external tools (so it is not really 'dead' in practise) should be somehow marked to assist the tools. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553303689 From mdonovan at openjdk.org Wed Nov 19 15:24:30 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 19 Nov 2025 15:24:30 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v3] In-Reply-To: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: > This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: > > > make test JTREG=MANUAL=true TEST=... > > > I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: reverted to original change and updated testing.{md,html} ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28381/files - new: https://git.openjdk.org/jdk/pull/28381/files/1cfa515d..7cbb1ddb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=01-02 Stats: 14 lines in 3 files changed: 13 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28381/head:pull/28381 PR: https://git.openjdk.org/jdk/pull/28381 From aph at openjdk.org Wed Nov 19 15:33:26 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 19 Nov 2025 15:33:26 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM On 19/11/2025 13:22, Matthias B?sken wrote: > MBaesken left a comment (openjdk/jdk#28319) > >> I remember s390 used to strip unneeded stuff, and it was very hard to debug anything. > > What exactly was hard to debug? > Did you use (fast)debug or product binaries ? > I do not remember issues like this on s390 but I can ask my (ex)colleagues who dealt more with s390 . It was hard to debug hotspot. Helpers such as pp(), back_trace(), and pfl() were missing. I think it was a release build, but of course you sometimes have to debug release builds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553349390 From aph at openjdk.org Wed Nov 19 15:39:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 19 Nov 2025 15:39:10 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: <9IgIs95wIgZ7ph5S69JEqYoKqitRnmg9pptrqzVCGkk=.5477177e-9402-498f-b858-876061977821@github.com> On Wed, 19 Nov 2025 15:03:33 GMT, Matthias Baesken wrote: > Btw on Linux s390x it is the `linktime-gc` , but from what I see this can be disabled by configure if you don't like it Yes, it can. Thankfully I don't usually need to debug hotspot in production s390 systems. I do, however, need to debug AArch64 on MacOS. This is a Very Bad Idea, and should not be dome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553368265 From mbaesken at openjdk.org Wed Nov 19 16:35:03 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 19 Nov 2025 16:35:03 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM Seems like we should fix the elimination of those debug helpers ; but those are only in the jvm lib. The situation in other libs is different. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553637974 From sgehwolf at openjdk.org Wed Nov 19 16:35:04 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 19 Nov 2025 16:35:04 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v8] In-Reply-To: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> References: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> Message-ID: <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com> On Fri, 14 Nov 2025 16:00:43 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > adapt review feedbacks src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 259: > 257: > 258: try (var r = new BufferedReader(new InputStreamReader(release.get()))) { > 259: return Optional.of(r.readLine()); As suggested on the CSR we should read the entire file, not just the first line and treat the entire content as a string in a specific encoding. While I wasn't able to get the JDK build a vendor name with new lines (due to jrt-fs.jar putting `COMPANYNAME` in the MANIFEST.MF) it's conceivable that some `release.txt` file might have more than one line. Alternatively we need to specify that the file must not contain line breaks or unusual encodings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2541860576 From cjplummer at openjdk.org Wed Nov 19 16:46:32 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Nov 2025 16:46:32 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> <4OIhZOkrBIfui3Hu5nfgmDklI_tL32E53tEJHq_CNJs=.59b581d7-0bad-42bb-aba3-347b06e952b5@github.com> Message-ID: On Wed, 19 Nov 2025 15:20:31 GMT, Matthias Baesken wrote: > There seem to be attributes for this kind of use case in clang, e.g. retain > https://reviews.llvm.org/D97447 > https://clang.llvm.org/docs/AttributeReference.html#retain > Should we add this to 'class Metadata' ? > If we can do it with attributes or something similar (and without changing lots of code locations) it sounds better to me than adjusting the coding. > 'Pseudo dead' stuff that is used from external tools (so it is not really 'dead' in practise) should be somehow marked to assist the tools. > There is also an attribute 'used' that looks similar. I tried the following but it didn't work. Perhaps I don't have the syntax right: --- a/src/hotspot/share/oops/metadata.hpp +++ b/src/hotspot/share/oops/metadata.hpp @@ -30,6 +30,7 @@ #include "utilities/ostream.hpp" // This is the base class for an internal Class related metadata +#pragma retain Metadata class Metadata : public MetaspaceObj { // Debugging hook to check that the metadata has not been deleted. NOT_PRODUCT(int _valid;) Note `retain` and `used` are listed under function attributes. They probably don't apply to data. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553656342 From cjplummer at openjdk.org Wed Nov 19 17:30:21 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Nov 2025 17:30:21 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM The following is how you declare a reference to the vtable: extern "C" void* _ZTV8Metadata[]; If you then reference _ZTV8Metadata from somewhere in a way that does not get dead stripped, that seems to fix the problem. The latter part is definitely very hacky. It would be nice to get a pragma working to keep the symbol from being deadstripped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3553874175 From cjplummer at openjdk.org Wed Nov 19 18:57:14 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 19 Nov 2025 18:57:14 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM This seems to work: extern void* _ZTV8Metadata[]; __attribute__((used)) void* foo() { return _ZTV8Metadata[0]; } You can put this anywhere since it does not reference any hotspot types. It just needs to be linked in with libjvm. Note I tried putting the "used" attribute on _ZTV8Metadata and getting rid of the foo() part, but I got the following warning and the vtable was dead stripped: `warning: 'used' attribute ignored on a non-definition declaration [-Wignored-attributes]` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3554180419 From aph at openjdk.org Wed Nov 19 19:11:02 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 19 Nov 2025 19:11:02 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Wed, 19 Nov 2025 16:31:58 GMT, Matthias Baesken wrote: > Seems like we should fix the elimination of those debug helpers ; but those are only in the jvm lib. The situation in other libs is different. Maybe, but it's not just the specific debug helpers. There are many functions in hotspot, and the maintenance programmer (in the case of Mac/AArch64, that's often me) will frequently type stuff like `print a->size()`. Linker options that strip "unused" code in binaries have been available for decades, and we haven't much used such options because they're a pain. Debugging on MacOS/AArch64 is a pain as it is, without making it worse. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3554226232 From erikj at openjdk.org Wed Nov 19 19:14:05 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 19 Nov 2025 19:14:05 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v3] In-Reply-To: References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Wed, 19 Nov 2025 15:24:30 GMT, Matthew Donovan wrote: >> This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: >> >> >> make test JTREG=MANUAL=true TEST=... >> >> >> I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > reverted to original change and updated testing.{md,html} doc/testing.md line 518: > 516: #### MANUAL > 517: > 518: Set to `true` to execute manual tests. I believe this will execute _only_ manual tests. > -m | -manual Only tests with /manual will be run ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28381#discussion_r2543241580 From duke at openjdk.org Wed Nov 19 19:51:57 2025 From: duke at openjdk.org (Nick Hall) Date: Wed, 19 Nov 2025 19:51:57 GMT Subject: RFR: 8349546: Linux support for Kerberos "nativeccache" functionality [v13] In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall wrote: >> _Purpose_ >> >> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX. >> >> _Rationale_ >> >> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches). There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types), This support already exists on MacOSX and Windows. >> >> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively. This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature). >> >> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses). It also fixes a (non problem) typo in the variable name in a function prototype. >> >> _Implementation Detail_ >> >> Note that there were multiple possible ways of doing this: >> >> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication. >> >> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences. This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect. >> >> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries. This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux. >> >> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result. Hopefully the additional jtreg test is sufficient to compensat... > > Nick Hall has updated the pull request incrementally with one additional commit since the last revision: > > Clean up jtreg run/compile directives, attend to other review comments There's prior art here for CUPS - this is a mandatory compile-time and run-time dependency. I guess the difference with CUPS is that Java can't print without it, whereas JAAS _can_ auth using Kerberos without my code, it's just limited to a file ccache. It turns out that this limitation actually works to our advantage. The existing code will first try and use the pure Java code to acquire a file ccache using a series of hard-coded defaults: * 1. KRB5CCNAME (bare file name without FILE:) * 2. /tmp/krb5cc_ on unix systems * 3. /krb5cc_ * 4. /krb5cc (if can't get ) (I'm not sure of the provenance of 3 and 4, but 1 and 2 are reasonable) It then checks that the crypto is something it can handle. If the code successfully finds a supported ccache, it will succeed _whether the new native lib is loadable or not_. If it does not find a supported ccache this way, it will then try and load the native lib (and potentially fail with an `UnsatisfiedLinkError`) at this point. (FWIW, I've tested this locally by temporarily making the system libkrb5 library inaccessible, then running a test with a regular FILE: ccache, and it worked as above.) Assuming we did build it in by default, I suspect most people using FILE: ccaches will not even get to the native library load - and anyone trying to use unsupported ccache types/crypto with an older Java version would have got an error anyway, it's just that now this might be an `UnsatisfiedLinkError` instead of a `LoginException`. I imagine this code was written this way for similar reasons to the discussion we're having here, on whichever of Windows/MacOS this was first introduced. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3554366847 From jrose at openjdk.org Wed Nov 19 20:35:01 2025 From: jrose at openjdk.org (John R Rose) Date: Wed, 19 Nov 2025 20:35:01 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v3] In-Reply-To: References: Message-ID: On Sun, 16 Nov 2025 01:10:40 GMT, Kim Barrett wrote: >> 8369187: Add wrapper for that forbids use of global allocation and deallocation functions >> >> Please review this change that adds `cppstdlib/new.hpp` as a wrapper for >> including ``. All existing inclusions of `` are changed to include >> the new wrapper. >> >> In additional to including ``, this wrapper also provides deprecation >> declarations to prevent the use of some facilities by HotSpot code. >> >> However, those deprecations need to be conditionalized to not apply to gtests, >> so this change also adds a macro definition provided by the build system for >> use in detecting that a header is being included by a gtest. >> >> Testing: mach5 tier1 > > Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' into wrap-stdlib-new > - poison implicit alloc/dealloc in globalDefinitions > - Merge branch 'master' into wrap-stdlib-new > - further conditionalize deprecation of hardare interference sizes > - add wrapper for Does what it says on the tin; good. (The stuff about hardware interference sizes seems a distraction, but I accept it?s part of the modern API for dynamic allocation, so away it goes. We can and should make our own platform-level queries as needed for this sort of thing.) ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28250#pullrequestreview-3484631257 From kbarrett at openjdk.org Wed Nov 19 20:59:01 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 19 Nov 2025 20:59:01 GMT Subject: Integrated: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 05:49:27 GMT, Kim Barrett wrote: > 8369187: Add wrapper for that forbids use of global allocation and deallocation functions > > Please review this change that adds `cppstdlib/new.hpp` as a wrapper for > including ``. All existing inclusions of `` are changed to include > the new wrapper. > > In additional to including ``, this wrapper also provides deprecation > declarations to prevent the use of some facilities by HotSpot code. > > However, those deprecations need to be conditionalized to not apply to gtests, > so this change also adds a macro definition provided by the build system for > use in detecting that a header is being included by a gtest. > > Testing: mach5 tier1 This pull request has now been integrated. Changeset: f5bc6ee9 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/f5bc6ee90d73da00cab5cad283b9517c692bc895 Stats: 207 lines in 15 files changed: 187 ins; 20 del; 0 mod 8369187: Add wrapper for that forbids use of global allocation and deallocation functions Reviewed-by: stefank, erikj, jrose ------------- PR: https://git.openjdk.org/jdk/pull/28250 From kbarrett at openjdk.org Wed Nov 19 20:58:58 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 19 Nov 2025 20:58:58 GMT Subject: RFR: 8369187: Add wrapper for that forbids use of global allocation and deallocation functions [v3] In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 09:10:46 GMT, Stefan Karlsson wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: >> >> - Merge branch 'master' into wrap-stdlib-new >> - poison implicit alloc/dealloc in globalDefinitions >> - Merge branch 'master' into wrap-stdlib-new >> - further conditionalize deprecation of hardare interference sizes >> - add wrapper for > > The last change seems reasonable to me. Thanks for reviews @stefank , @erikj79 , and @rose00 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28250#issuecomment-3554597814 From serb at openjdk.org Wed Nov 19 22:14:27 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 19 Nov 2025 22:14:27 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT @azvegint please verify this patch by the mach5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3554830496 From mdonovan at openjdk.org Wed Nov 19 23:46:38 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Wed, 19 Nov 2025 23:46:38 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v4] In-Reply-To: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: > This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: > > > make test JTREG=MANUAL=true TEST=... > > > I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: tweaked testing doc for clarity ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28381/files - new: https://git.openjdk.org/jdk/pull/28381/files/7cbb1ddb..f650c58c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28381/head:pull/28381 PR: https://git.openjdk.org/jdk/pull/28381 From erikj at openjdk.org Wed Nov 19 23:54:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 19 Nov 2025 23:54:56 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v4] In-Reply-To: References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: On Wed, 19 Nov 2025 23:46:38 GMT, Matthew Donovan wrote: >> This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: >> >> >> make test JTREG=MANUAL=true TEST=... >> >> >> I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > tweaked testing doc for clarity doc/testing.md line 458: > 456: issues, the special value `%20` can be used instead of space. > 457: > 458: It looks like an accidental extra newline was added here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28381#discussion_r2543902940 From mdonovan at openjdk.org Thu Nov 20 00:01:33 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 20 Nov 2025 00:01:33 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v5] In-Reply-To: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: > This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: > > > make test JTREG=MANUAL=true TEST=... > > > I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: removed rogue new line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28381/files - new: https://git.openjdk.org/jdk/pull/28381/files/f650c58c..69b50cb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28381&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28381.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28381/head:pull/28381 PR: https://git.openjdk.org/jdk/pull/28381 From aph at openjdk.org Thu Nov 20 09:44:45 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 20 Nov 2025 09:44:45 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Fri, 14 Nov 2025 11:25:05 GMT, Matthias Baesken wrote: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem. Maybe if we only do this on non-PRODUCT builds it's be OK, but it would require very careful thought and analysis. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3556915717 From duke at openjdk.org Thu Nov 20 11:48:35 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 20 Nov 2025 11:48:35 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I Message-ID: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I ------------- Commit messages: - 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I Changes: https://git.openjdk.org/jdk/pull/28420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371629 Stats: 107 lines in 16 files changed: 91 ins; 1 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/28420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28420/head:pull/28420 PR: https://git.openjdk.org/jdk/pull/28420 From jpai at openjdk.org Thu Nov 20 12:00:16 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 20 Nov 2025 12:00:16 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:34:46 GMT, serhiysachkov wrote: > Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I Hello Serhiy, my opinion is that we shouldn't be adding this change to every single test file. When a test is run, typically in CI or locally, it runs as part of several other tests on a specific host. The `IPSupport.printPlatformSupport(...)` prints host specific details and not test specific details, so calling this in every single test would generate redundant output and would require update and future additions to every single test within the networking area. If this information isn't already captured in the jtreg failure handlers of the JDK, then I think we should enhance those failure handlers so that this same information gets collected just once when there is a test failure or a timeout. That I think should avoid all these test updates. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3557626595 From dfuchs at openjdk.org Thu Nov 20 12:26:21 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 20 Nov 2025 12:26:21 GMT Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a lock [v2] In-Reply-To: References: Message-ID: > An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool. > > The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool. > > This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test. > > To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock. Daniel Fuchs 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 two additional commits since the last revision: - Merge branch 'SelectorManagerVT-8372159' into ConnectionCloseLock-8372198 - 8372198: Avoid closing PlainHttpConnection while holding a lock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28421/files - new: https://git.openjdk.org/jdk/pull/28421/files/177e7ee3..97ce3737 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28421&range=00-01 Stats: 19751 lines in 348 files changed: 10987 ins; 5712 del; 3052 mod Patch: https://git.openjdk.org/jdk/pull/28421.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28421/head:pull/28421 PR: https://git.openjdk.org/jdk/pull/28421 From dfuchs at openjdk.org Thu Nov 20 12:26:22 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 20 Nov 2025 12:26:22 GMT Subject: RFR: 8372198: Avoid closing PlainHttpConnection while holding a lock In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs wrote: > An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool. > > The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool. > > This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test. > > To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock. Something went wrong when I tried to merge the main PR branch in the dependent PR branch. I'm going to withdraw this PR and start again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28421#issuecomment-3557752299 From dfuchs at openjdk.org Thu Nov 20 12:26:23 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 20 Nov 2025 12:26:23 GMT Subject: Withdrawn: 8372198: Avoid closing PlainHttpConnection while holding a lock In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:38:08 GMT, Daniel Fuchs wrote: > An experimental change to SelectorManager::shutdown unveil a potential deadlock between the SelectorManager thread trying to stop the HttpClientImpl, and an executor thread concurrently trying to return a connection to the pool. > > The issue seems to be caused by the ConnectionPool::returnToPool trying to close the returned connection when stopping, while holding the ConnectionPool state lock, and the SelectorManager thread trying to close a pooled connection, holding the connection stateLock and trying to close the channel, which caused the CleanupTrigger to fire and attempt to remove the connection from the pool. > > This problem was observed once with the java/net/httpclient/ThrowingSubscribersAsLimitingAsync.java test. > > To avoid the problem, the proposed fix is to wait until the ConnectionPool::stateLock has been released before actually closing the connection, and to wait until the PlainHttpConnection::stateLock has been released before actually closing the channel. Indeed, there should be no need to close those while holding the lock. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28421 From duke at openjdk.org Thu Nov 20 12:43:53 2025 From: duke at openjdk.org (serhiysachkov) Date: Thu, 20 Nov 2025 12:43:53 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 11:57:35 GMT, Jaikiran Pai wrote: > Hello Serhiy, my opinion is that we shouldn't be adding this change to every single test file. When a test is run, typically in CI or locally, it runs as part of several other tests on a specific host. The `IPSupport.printPlatformSupport(...)` prints host specific details and not test specific details, so calling this in every single test would generate redundant output and would require update and future additions to every single test within the networking area. > > If this information isn't already captured in the jtreg failure handlers of the JDK, then I think we should enhance those failure handlers so that this same information gets collected just once when there is a test failure or a timeout. That I think should avoid all these test updates. Hi Jaikiran, this output would help during ATR failure analysis, as experience of previous ones shows there are a lot of communication going on during this period on env setup especially in IPv6 testing, so the idea is to save some time for those back and forward communications in clearing out testing environments when 3rd party is involved in testing. Plus it's a background for future changes, that will involve runs with specific JVM option as -Djava.net.PreferIPv6Addresses in IPV6 only and mixed env. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3557840486 From msheppar at openjdk.org Thu Nov 20 13:01:44 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 20 Nov 2025 13:01:44 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 11:57:35 GMT, Jaikiran Pai wrote: >> Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I > > Hello Serhiy, my opinion is that we shouldn't be adding this change to every single test file. > When a test is run, typically in CI or locally, it runs as part of several other tests on a specific host. The `IPSupport.printPlatformSupport(...)` prints host specific details and not test specific details, so calling this in every single test would generate redundant output and would require update and future additions to every single test within the networking area. > > If this information isn't already captured in the jtreg failure handlers of the JDK, then I think we should enhance those failure handlers so that this same information gets collected just once when there is a test failure or a timeout. That I think should avoid all these test updates. @jaikiran This is not just about test failures in IPv6 environments, but also that the test that pass are also correctly passing. It will also assist in diagnosing failures in the CI pipelines. It is to assist is determining if anomalous behaviour is due to a dynamic configuration change in a test environment. It is to ensure that there is a consistent configuration and setup during the execution of the networking tests in an IPv6 only env. Ask yourself why there are so many TCP4 connections rather than TCP4,6 connections in the failures associated with https://bugs.openjdk.org/browse/JDK-8273158 ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3557926075 From mbaesken at openjdk.org Thu Nov 20 13:22:26 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 13:22:26 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken wrote: >> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. >> See for example this manpage : >> https://manpages.debian.org/testing/lld-7/ld.lld-7.1 >> >> >> sizes of libjvm.so with / without -icf=all >> linux aarch64 : 25888 / 27112 K >> linux x86_64 : 27952 / 29072 K >> >> >> (for most other native libs the identical code folding has no effect, because there is nothing to fold) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Limit icf to release builds Any comments / revies from HS developers ? @dholmes-ora , any comments on this one ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3558018238 From erikj at openjdk.org Thu Nov 20 14:02:33 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Nov 2025 14:02:33 GMT Subject: RFR: 8247690: RunTest does not support running of JTREG manual tests [v5] In-Reply-To: References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: <5HTADCSD1KrZCkYOtLeUkWpaU5sD9JHhLNFubW92IAs=.59c75557-6784-4bd9-816c-5b0f7d67d3e6@github.com> On Thu, 20 Nov 2025 00:01:33 GMT, Matthew Donovan wrote: >> This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: >> >> >> make test JTREG=MANUAL=true TEST=... >> >> >> I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > removed rogue new line Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28381#pullrequestreview-3488017137 From mdonovan at openjdk.org Thu Nov 20 14:13:09 2025 From: mdonovan at openjdk.org (Matthew Donovan) Date: Thu, 20 Nov 2025 14:13:09 GMT Subject: Integrated: 8247690: RunTest does not support running of JTREG manual tests In-Reply-To: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> References: <_5yfmtrdSCj3-coVduLGlmBQW0oW8O9SAEeXm_ZiVxw=.f2ce7c6f-617b-43d3-a533-c4692eea764e@github.com> Message-ID: <68PtHnZud2h7mEb6BrEJZ7fgbFtT6UeUfdCxIYYRDko=.1fec9796-9dc5-43dd-a621-9d479f2b0105@github.com> On Tue, 18 Nov 2025 20:29:50 GMT, Matthew Donovan wrote: > This PR adds a make keyword, MANUAL, to run manual tests with the make command e.g.: > > > make test JTREG=MANUAL=true TEST=... > > > I've gotten into the habit of running tests with make and although this doesn't come up often, I have wanted the functionality for a while. This pull request has now been integrated. Changeset: f125c76f Author: Matthew Donovan URL: https://git.openjdk.org/jdk/commit/f125c76f5b53d90a09f58c22d6def7d843feaa50 Stats: 14 lines in 3 files changed: 12 ins; 0 del; 2 mod 8247690: RunTest does not support running of JTREG manual tests Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/28381 From alanb at openjdk.org Thu Nov 20 14:33:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 20 Nov 2025 14:33:00 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I In-Reply-To: References: Message-ID: <1mrIlQMT85mj-s4V4ys5T0f8Qbt811XkDJXr3gA1zCQ=.735c80d7-6790-4510-8168-5618b43e15ef@github.com> On Thu, 20 Nov 2025 10:34:46 GMT, serhiysachkov wrote: > Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I I have my doubts on the usefulness of this as IPSupport.printPlatformSupport doesn't print the network configuration. If there is dynamic reconfiguration going on (and I agree that is hard to diagnose) then dumping the network configuration in the jtreg failure handler would be useful if it's not there already. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3558353546 From alanb at openjdk.org Thu Nov 20 14:37:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 20 Nov 2025 14:37:19 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 10:34:46 GMT, serhiysachkov wrote: > Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I test/jdk/java/nio/channels/AsynchronousSocketChannel/CompletionHandlerRelease.java line 154: > 152: @BeforeClass > 153: void printSupportedPlatforms(){ > 154: IPSupport.printPlatformSupport(System.out); FYI: JUnit prints to System.err rather than System.out so need to specify System.err to get it inlined in the output. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28420#discussion_r2546263841 From mbaesken at openjdk.org Thu Nov 20 14:39:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 14:39:57 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Thu, 20 Nov 2025 09:42:41 GMT, Andrew Haley wrote: > On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem Thanks for looking into it. I can disable the dead_strip switch for the debug-builds, so it would not eliminate these helpers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558388446 From mbaesken at openjdk.org Thu Nov 20 14:42:28 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 14:42:28 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Wed, 19 Nov 2025 18:53:34 GMT, Chris Plummer wrote: > This seems to work: > > ``` > extern void* _ZTV8Metadata[]; > > __attribute__((used)) > void* foo() { > return _ZTV8Metadata[0]; > } > ``` > > You can put this anywhere since it does not reference any hotspot types. It just needs to be linked in with libjvm. Note I tried putting the "used" attribute on _ZTV8Metadata and getting rid of the foo() part, but I got the following warning and the vtable was dead stripped: > > `warning: 'used' attribute ignored on a non-definition declaration [-Wignored-attributes]` Thanks for the testing and providing the workaround. Too bad that the 'retain' and 'used' are only function attributes, this makes things a bit harder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558408585 From mbaesken at openjdk.org Thu Nov 20 14:57:12 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 14:57:12 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size [v2] In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: _ZTV8Metadata should not be eliminated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28319/files - new: https://git.openjdk.org/jdk/pull/28319/files/1c5a43f4..07251ffe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=00-01 Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28319/head:pull/28319 PR: https://git.openjdk.org/jdk/pull/28319 From aboldtch at openjdk.org Thu Nov 20 15:04:10 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Nov 2025 15:04:10 GMT Subject: RFR: 8371346: ZGC: Flexible heap base selection [v2] In-Reply-To: References: Message-ID: > ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base. > > Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties. > > With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM. > > This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base. > > I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits. > > The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that. > > On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. > > There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. > > Performance testing show no significant differences. > > Testing: > * GHA > * Running ZGC tier1-8 on Oracle supported platforms Axel Boldt-Christmas 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 11 additional commits since the last revision: - Small fixes - Merge remote-tracking branch 'upstream_jdk/master' into stefank_review_pr_28161 - Fixes and cleanups - pr/28161_review - Merge remote-tracking branch 'upstream/master' into pr/28161 - Initial Test Implementation - Initial implementation flexible heap base - Constrain ZAddressOffsetMax correctly when multi-partition fails - Log reserved size correctly when multi-partition fails - Cleanup headers - ... and 1 more: https://git.openjdk.org/jdk/compare/168f0580...1d7b2374 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28161/files - new: https://git.openjdk.org/jdk/pull/28161/files/bf5f9550..1d7b2374 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=00-01 Stats: 263285 lines in 2103 files changed: 168784 ins; 56747 del; 37754 mod Patch: https://git.openjdk.org/jdk/pull/28161.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28161/head:pull/28161 PR: https://git.openjdk.org/jdk/pull/28161 From aboldtch at openjdk.org Thu Nov 20 15:08:29 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 20 Nov 2025 15:08:29 GMT Subject: RFR: 8371346: ZGC: Flexible heap base selection [v2] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 15:04:10 GMT, Axel Boldt-Christmas wrote: >> ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base. >> >> Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties. >> >> With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM. >> >> This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base. >> >> I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits. >> >> The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that. >> >> On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. >> >> There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. >> >> Performance testing show no significant differences. >> >> Testing: >> * GHA >> * Running ZGC tier1-8 on Oracle supported platforms > > Axel Boldt-Christmas 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 11 additional commits since the last revision: > > - Small fixes > - Merge remote-tracking branch 'upstream_jdk/master' into stefank_review_pr_28161 > - Fixes and cleanups > - pr/28161_review > - Merge remote-tracking branch 'upstream/master' into pr/28161 > - Initial Test Implementation > - Initial implementation flexible heap base > - Constrain ZAddressOffsetMax correctly when multi-partition fails > - Log reserved size correctly when multi-partition fails > - Cleanup headers > - ... and 1 more: https://git.openjdk.org/jdk/compare/3d39bb21...1d7b2374 We redesigned a bit how the `ZVirtualMemoryManager` works. We no longer update global state while trying to find a reservation. But have created a distinct separation between when we are looking for a heap and when we have found a heap. Prior to finding a heap we do not use our heap based types `zaddress`, `zpointer`, `zoffset` etc. And if we did they would assert. Then at the point when we are satisfied with a specific heap selection, we set up our global state based on this heap selection, once and only once. We then start transferring our heap selection into our heap data structures which use these heap based types. As a consequence we had to rewrite some of the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28161#issuecomment-3558539681 From msheppar at openjdk.org Thu Nov 20 15:23:45 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Thu, 20 Nov 2025 15:23:45 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I In-Reply-To: <1mrIlQMT85mj-s4V4ys5T0f8Qbt811XkDJXr3gA1zCQ=.735c80d7-6790-4510-8168-5618b43e15ef@github.com> References: <1mrIlQMT85mj-s4V4ys5T0f8Qbt811XkDJXr3gA1zCQ=.735c80d7-6790-4510-8168-5618b43e15ef@github.com> Message-ID: On Thu, 20 Nov 2025 14:29:46 GMT, Alan Bateman wrote: > I have my doubts on the usefulness of this as IPSupport.printPlatformSupport doesn't print the network configuration. If there is dynamic reconfiguration going on (and I agree that is hard to diagnose) then dumping the network configuration in the jtreg failure handler would be useful if it's not there already. Yes, the network configuration is printed in the jtreg handler. BUT, wrt this addition, we are not looking for network configuration (at this juncture). We wish to determine what is the "perception" of the JDK runtime, used in the test, wrt IPv4 and IPv6 support and correlate that with the configuration i.e. IPv6 only. Has it created a socket in the correct domain etc., has the OS been (accidentally) altered to enable IPv4, while it may not have it configured. If preferIPv4Stack is set true, why has a test not failed. Additionally, this is not just for failures. It is also to allow review of successful test execution, and to ensure the consistency of behaviour within IPv6 only environments. Prior to running test in IPv6 only environments, we run a set of sanity checks, which are set standalone tests verifying the configured environments. We capture the network configuration for comparison with the jtreg failure capture. We do a lot of preparation to ensure the env are setup correctly. But anomalies have been observed, which have raised question on the veracity of the tests. This change is to assist in evaluating the test JDK runtime thinks it is using and what has been configured. It's a small addition which goes a long way to helping the analysis ------------- PR Comment: https://git.openjdk.org/jdk/pull/28420#issuecomment-3558633339 From azvegint at openjdk.org Thu Nov 20 15:44:24 2025 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Thu, 20 Nov 2025 15:44:24 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 22:11:35 GMT, Sergey Bylokhov wrote: > @azvegint please verify this patch by the mach5. clientlibs is all green. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3558726324 From aph at openjdk.org Thu Nov 20 15:54:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 20 Nov 2025 15:54:55 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Thu, 20 Nov 2025 14:36:31 GMT, Matthias Baesken wrote: > > On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem > > Thanks for looking into it. I can disable the dead_strip switch for the debug-builds, so it would not eliminate these helpers. Right, but we'll need to make sure we don't remove the non-debug ones. We don't want to exclude stuff in `src/hotspot/share/utilities/debug.cpp` or explicit helpers in the back ends. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558785722 From mbaesken at openjdk.org Thu Nov 20 16:00:30 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 16:00:30 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size [v3] In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: > The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. > Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : > (before -> after setting the option) > > 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib > 264K -> 248K images/jdk/lib/libjavajpeg.dylib > 152K -> 132K images/jdk/lib/libjli.dylib > 388K -> 296K images/jdk/lib/liblcms.dylib > 164K -> 128K images/jdk/lib/libzip.dylib > > > and libjvm : > > 20M -> 18M images/jdk/lib/server/libjvm.dylib > 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Fix Windows issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28319/files - new: https://git.openjdk.org/jdk/pull/28319/files/07251ffe..b41966b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28319.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28319/head:pull/28319 PR: https://git.openjdk.org/jdk/pull/28319 From mbaesken at openjdk.org Thu Nov 20 16:08:23 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 16:08:23 GMT Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3] In-Reply-To: References: Message-ID: On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken wrote: >> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments. >> See for example this manpage : >> https://manpages.debian.org/testing/lld-7/ld.lld-7.1 >> >> >> sizes of libjvm.so with / without -icf=all >> linux aarch64 : 25888 / 27112 K >> linux x86_64 : 27952 / 29072 K >> >> >> (for most other native libs the identical code folding has no effect, because there is nothing to fold) > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Limit icf to release builds sizes of libjvm.so with / without -icf=all linux x86_64 : 27952 / 29072 K With `-icf=safe` it is on linux x86_64 ` 28656 K ` , so the lib is still smaller but not as much as with ` -icf=all` . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3558843260 From mbaesken at openjdk.org Thu Nov 20 16:31:25 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 16:31:25 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size [v3] In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Thu, 20 Nov 2025 16:00:30 GMT, Matthias Baesken wrote: >> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. >> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : >> (before -> after setting the option) >> >> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib >> 264K -> 248K images/jdk/lib/libjavajpeg.dylib >> 152K -> 132K images/jdk/lib/libjli.dylib >> 388K -> 296K images/jdk/lib/liblcms.dylib >> 164K -> 128K images/jdk/lib/libzip.dylib >> >> >> and libjvm : >> >> 20M -> 18M images/jdk/lib/server/libjvm.dylib >> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Fix Windows issues Interestingly, we seem to rely already on the 'used' attribute in the OpenJDK codebase at some places, see https://github.com/search?q=repo%3Aopenjdk%2Fjdk%20ATTRIBUTE_USED&type=code ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3558965415 From mbaesken at openjdk.org Thu Nov 20 16:44:08 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 20 Nov 2025 16:44:08 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size [v3] In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Thu, 20 Nov 2025 16:00:30 GMT, Matthias Baesken wrote: >> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols. >> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) : >> (before -> after setting the option) >> >> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib >> 264K -> 248K images/jdk/lib/libjavajpeg.dylib >> 152K -> 132K images/jdk/lib/libjli.dylib >> 388K -> 296K images/jdk/lib/liblcms.dylib >> 164K -> 128K images/jdk/lib/libzip.dylib >> >> >> and libjvm : >> >> 20M -> 18M images/jdk/lib/server/libjvm.dylib >> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Fix Windows issues For the Apple linker there seem to be also a way to mark some sections with `S_ATTR_NO_DEAD_STRIP` to avoid the dead strip operation https://maskray.me/blog/2021-02-28-linker-garbage-collection 'Sections with the S_ATTR_NO_DEAD_STRIP flag' But I am not sure how to do this in the HS code directly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3559017189 From cjplummer at openjdk.org Thu Nov 20 17:23:47 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 20 Nov 2025 17:23:47 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Thu, 20 Nov 2025 15:51:55 GMT, Andrew Haley wrote: > > > On further consideration, I remembered that many of the helpers are debug-only, so that shouldn't be a problem > > > > > > Thanks for looking into it. I can disable the dead_strip switch for the debug-builds, so it would not eliminate these helpers. > > Right, but we'll need to make sure we don't remove the non-debug ones. We don't want to exclude stuff in `src/hotspot/share/utilities/debug.cpp` or explicit helpers in the back ends. Most of the debug.cpp helpers are in product builds now. I think only pns() and pns2() are left out of product builds. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3559202033 From erikj at openjdk.org Thu Nov 20 17:42:25 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Nov 2025 17:42:25 GMT Subject: RFR: 8371346: ZGC: Flexible heap base selection [v2] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 15:04:10 GMT, Axel Boldt-Christmas wrote: >> ZGC reserves a virtual address range for its heap with one high order bit set which is referred to as the heap base. Internally we then often represent heap addresses as offset from this heap base. >> >> Currently we select one specific heap base at the start based on MaxHeapSize and the current system properties. >> >> With instrumented builds, or custom launchers it may be that we are unable to reserve a usable address range using that heap base. Currently we just give up if this happens and exits the VM. >> >> This is problematic when using instrumented builds such as ASAN where there are certain address ranges it uses which often clash with the default ZGC heap base. >> >> I propose that we are more flexible when selecting the heap base, and we start as we do today at our preferred location, but are able to retry other compatible heap bases within some broader limits. >> >> The implementation will now start at the recommended or required heap base which ever is larger and try to first reserve the desired reservation size (normally 16 * MaxHeapSize). If no heap base can accommodate this desired size, it will attempt to find at least the required size and use that. >> >> On linux x86_64 we will now also probe for the heap base rather than hard coding the max heap base as we did previously. This is beneficial when there are address space restrictions (such as with ASAN), and when there are none, we only do a couple of extra system calls at most. >> >> There are some changes to the gc+init logging. The ZAddressOffsetMax is adjusted to always be a correct upper bound. And the exit path when reservation fails is clean up, so that we exit early when we know that the external virtual memory limits will prohibit the heap reservation. >> >> Performance testing show no significant differences. >> >> Testing: >> * GHA >> * Running ZGC tier1-8 on Oracle supported platforms > > Axel Boldt-Christmas 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 11 additional commits since the last revision: > > - Small fixes > - Merge remote-tracking branch 'upstream_jdk/master' into stefank_review_pr_28161 > - Fixes and cleanups > - pr/28161_review > - Merge remote-tracking branch 'upstream/master' into pr/28161 > - Initial Test Implementation > - Initial implementation flexible heap base > - Constrain ZAddressOffsetMax correctly when multi-partition fails > - Log reserved size correctly when multi-partition fails > - Cleanup headers > - ... and 1 more: https://git.openjdk.org/jdk/compare/52f64ca1...1d7b2374 Build change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28161#pullrequestreview-3489100120 From erikj at openjdk.org Thu Nov 20 17:45:28 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 20 Nov 2025 17:45:28 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3489112220 From henryjen at openjdk.org Thu Nov 20 19:07:38 2025 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 20 Nov 2025 19:07:38 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v8] In-Reply-To: <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com> References: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com> Message-ID: On Wed, 19 Nov 2025 12:47:14 GMT, Severin Gehwolf wrote: >> Henry Jen has updated the pull request incrementally with one additional commit since the last revision: >> >> adapt review feedbacks > > src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 259: > >> 257: >> 258: try (var r = new BufferedReader(new InputStreamReader(release.get()))) { >> 259: return Optional.of(r.readLine()); > > As suggested on the CSR we should read the entire file, not just the first line and treat the entire content as a string in a specific encoding. While I wasn't able to get the JDK build a vendor name with new lines (due to jrt-fs.jar putting `COMPANYNAME` in the MANIFEST.MF) it's conceivable that some `release.txt` file might have more than one line. > > Alternatively we need to specify that the file must not contain line breaks or unusual encodings. The proposal is to have a one line release signature set up by the build, briefly discussed the possibility to use a java properties file format as the current release file distributed with JDK, but then a simplified approach of one signature is preferred. I'll update the PR once we come to conclusion with the CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2547306781 From jwaters at openjdk.org Fri Nov 21 06:18:31 2025 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 21 Nov 2025 06:18:31 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: <9rA2TTpNljE7FkFoJm1xAWnBX67WMakn4Jnch-duNfc=.24ffb34c-628b-49df-a331-4016ab13ab65@github.com> On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Not really fond of the way this was done, but oh well, I can live with the changes regardless. make/autoconf/flags-cflags.m4 line 327: > 325: C_O_FLAG_NONE="-Od" > 326: C_O_FLAG_SIZE="-O1" > 327: C_O_FLAG_LTO="-GL" There is sometimes warning spam during linking if -Gy is not set alongside -GL last I remember. This probably won't break LTO builds, but it could possibly be annoying. Whether you want to add the flag is up to you, however. ------------- PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3491340499 PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2548662231 From mbaesken at openjdk.org Fri Nov 21 08:33:24 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 21 Nov 2025 08:33:24 GMT Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to reduce binary size In-Reply-To: References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com> Message-ID: On Wed, 19 Nov 2025 13:05:24 GMT, Matthias Baesken wrote: > As usual, maybe it is possible to split this patch between hotspot and the libraries? Maybe we should for now limit the dead_strip to the JDK native libs ? This would avoid the trouble with the HS debug helpers coding and the serviceability agent (but in the long run we have this trouble also with linktime-gc and probably LTO which can be enabled by OpenJDK configure, not only with this macOS-linker related flag this PR is about ). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3561953592 From duke at openjdk.org Fri Nov 21 11:22:26 2025 From: duke at openjdk.org (serhiysachkov) Date: Fri, 21 Nov 2025 11:22:26 GMT Subject: RFR: 8371629: Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 14:24:21 GMT, Alan Bateman wrote: >> Add diagnostic output IPSupport.printPlatformSupport(System.out) to tests in java/nio/channels directory -- part I > > test/jdk/java/nio/channels/AsynchronousSocketChannel/CompletionHandlerRelease.java line 154: > >> 152: @BeforeClass >> 153: void printSupportedPlatforms(){ >> 154: IPSupport.printPlatformSupport(System.out); > > FYI: JUnit prints to System.err rather than System.out so need to specify System.err to get it inlined in the output. We will be able to update it when test will be refactored to use JUnit instead of TestNG as part of further improvements mentioned above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28420#discussion_r2549429470 From mbaesken at openjdk.org Fri Nov 21 12:35:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 21 Nov 2025 12:35:59 GMT Subject: RFR: 8370438: Offer link time optimization support on library level In-Reply-To: References: <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com> <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com> Message-ID: On Tue, 4 Nov 2025 13:37:11 GMT, Erik Joelsson wrote: >>>It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. >> >> The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this >> >> >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ >> -fuse-linker-plugin -fno-strict-aliasing >> => >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) > >> > It would be a little awkward to refactor only the JVM LTO flags into configure flags while leaving the rest of the JVM feature flags set by the Makefile, just my 2 cents. >> >> The part in the Makefile would probably stay, but could reuse common flags from configure, e.g. something like this >> >> ``` >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) -flto=auto \ >> -fuse-linker-plugin -fno-strict-aliasing >> => >> JVM_LDFLAGS_FEATURES += $(CXX_O_FLAG_HIGHEST_JVM) $(LDFLAGS_LTO) >> ``` > > Yes, please only define the values once and use the variables in the JVM makefile. @erikj79 thanks for the review ! @mrserb are you fine with the change as it is now ? @tstuefe maybe you can test it to see if there are issues with your specific toolchain versions at IBM and/or RedHat ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3562836140 From mbaesken at openjdk.org Fri Nov 21 12:35:59 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 21 Nov 2025 12:35:59 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: <9rA2TTpNljE7FkFoJm1xAWnBX67WMakn4Jnch-duNfc=.24ffb34c-628b-49df-a331-4016ab13ab65@github.com> References: <9rA2TTpNljE7FkFoJm1xAWnBX67WMakn4Jnch-duNfc=.24ffb34c-628b-49df-a331-4016ab13ab65@github.com> Message-ID: <2Y4KNmCMKy1c6vU0HoaQqrX48YKEzmkdKM_zkERZ77g=.2ff9709b-3f4f-490e-8150-65c54c4dd225@github.com> On Fri, 21 Nov 2025 06:15:09 GMT, Julian Waters wrote: >> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: >> >> Add lto to EXTRA_FLAGS, not to OPT > > make/autoconf/flags-cflags.m4 line 327: > >> 325: C_O_FLAG_NONE="-Od" >> 326: C_O_FLAG_SIZE="-O1" >> 327: C_O_FLAG_LTO="-GL" > > There is sometimes warning spam during linking if -Gy is not set alongside -GL last I remember. This probably won't break LTO builds, but it could possibly be annoying. Whether you want to add the flag is up to you, however. We build with VS2022 and I cannot see issues/spam . What would it look like? Is it something we only see with older VS versions ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27976#discussion_r2549614850 From alanb at openjdk.org Fri Nov 21 15:22:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 21 Nov 2025 15:22:24 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v8] In-Reply-To: References: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com> Message-ID: On Thu, 20 Nov 2025 19:01:53 GMT, Henry Jen wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 259: >> >>> 257: >>> 258: try (var r = new BufferedReader(new InputStreamReader(release.get()))) { >>> 259: return Optional.of(r.readLine()); >> >> As suggested on the CSR we should read the entire file, not just the first line and treat the entire content as a string in a specific encoding. While I wasn't able to get the JDK build a vendor name with new lines (due to jrt-fs.jar putting `COMPANYNAME` in the MANIFEST.MF) it's conceivable that some `release.txt` file might have more than one line. >> >> Alternatively we need to specify that the file must not contain line breaks or unusual encodings. > > The proposal is to have a one line release signature set up by the build, briefly discussed the possibility to use a java properties file format as the current release file distributed with JDK, but then a simplified approach of one signature is preferred. > > I'll update the PR once we come to conclusion with the CSR. It might be useful to see what breaks if a JDK were built with a newline in the vendor name, I assume other things will break. Overall I think the changes are looking good, the main thing is that the error message is clear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2550103816 From sgehwolf at openjdk.org Fri Nov 21 15:42:59 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 21 Nov 2025 15:42:59 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v8] In-Reply-To: References: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com> Message-ID: On Fri, 21 Nov 2025 15:18:48 GMT, Alan Bateman wrote: > It might be useful to see what breaks if a JDK were built with a newline in the vendor name, I assume other things will break. Writhing the manifest entries for `jrt-fs.jar` break (header validation fails). Since the vendor populates to that jar file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2550173160 From sherman at openjdk.org Fri Nov 21 23:56:05 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 21 Nov 2025 23:56:05 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v10] In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: <_VpQ_oPGP6BR3DP_ZfSDtevk2cwePjo95duU3NQloOk=.5d80b35b-fc4b-441d-8a0e-9e038047fff5@github.com> > ### Summary > > Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. > > Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: > > **String.equalsIgnoreCase(String)** > > - Unicode-aware, locale-independent. > - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. > - Limited: does not support 1:M mapping defined in Unicode case folding. > > **Character.toLowerCase(int) / Character.toUpperCase(int)** > > - Locale-independent, single code point only. > - No support for 1:M mappings. > > **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** > > - Based on Unicode SpecialCasing.txt, supports 1:M mappings. > - Intended primarily for presentation/display, not structural case-insensitive matching. > - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. > > **1:M mapping example, U+00DF (?)** > > - String.toUpperCase(Locale.ROOT, "?") ? "SS" > - Case folding produces "ss", matching Unicode caseless comparison rules. > > > jshell> "\u00df".equalsIgnoreCase("ss") > $22 ==> false > > jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") > $24 ==> true > > > ### Motivation & Direction > > Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. > > - Unicode-compliant **full** case folding. > - Simpler, stable and more efficient case-less matching without workarounds. > - Brings Java's string comparison handling in line with other programming languages/libraries. > > This PR proposes to introduce the following comparison methods in `String` class > > - boolean equalsFoldCase(String anotherString) > - int compareToFoldCase(String anotherString) > - Comparator UNICODE_CASEFOLD_ORDER > > These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. > > *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. > However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. > > ### The New API > > See CSR https://bugs.openjd... Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: doc update - add spec tag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27628/files - new: https://git.openjdk.org/jdk/pull/27628/files/057ea814..0aafb674 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=08-09 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27628.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628 PR: https://git.openjdk.org/jdk/pull/27628 From serb at openjdk.org Sun Nov 23 22:39:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 23 Nov 2025 22:39:32 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters wrote: >> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated. >> >> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer >> - -flto is set to $(JOBS) instead of auto to better match what the user requested >> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least > > Julian Waters 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 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-16 > - -fno-omit-frame-pointer in JvmFeatures.gmk > - Revert compilerWarnings_gcc.hpp > - General LTO fixes JvmFeatures.gmk > - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp > - Merge branch 'openjdk:master' into patch-16 > - Revert os.cpp > - Fix memory leak in jvmciEnv.cpp > - Stopgap fix in os.cpp > - Declaration fix in compilerWarnings_gcc.hpp > - ... and 2 more: https://git.openjdk.org/jdk/compare/3cbd7aa6...9d05cb8e Just curious, how did you check that the ?no omit frame pointer? option is needed? Did you see any test failures? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3568414088 From serb at openjdk.org Sun Nov 23 22:57:35 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 23 Nov 2025 22:57:35 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: Message-ID: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken wrote: >> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature. >> But for other JDK native libs, we do not have support for this feature. >> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Add lto to EXTRA_FLAGS, not to OPT Marked as reviewed by serb (Reviewer). here is my finding, no issues were found by the tests: Platform / Compiler | Before | After | Win (number) | Win (%) -- | -- | -- | -- | -- Windows, VS 2022 | 204 800 | 206 848 | ?2 048 | ?1.00% macOS, Xcode 14.3.1 | 335 664 | 219 568 | 116 096 | 34.57% macOS, Xcode 26 | 391 168 | 237 360 | 153 808 | 39.32% gcc 13.3.0 | 307 936 | 219 344 | 88 592 | 28.77% gcc 11.4.0 | 303 944 | 174 168 | 129 776 | 42.70% gcc 11.5.0 | 295 280 | 177 360 | 117 920 | 39.93% ------------- PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3498070608 PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3568427441 From jwaters at openjdk.org Mon Nov 24 08:03:44 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 24 Nov 2025 08:03:44 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: On Sun, 23 Nov 2025 22:35:53 GMT, Sergey Bylokhov wrote: > Just curious, how did you check that the ?no omit frame pointer? option is needed? Did you see any test failures? gcc documentation states that you typically need to pass the same options to the link step from the compile step, since the linker when LTO is active is actually the compiler in disguise. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3569393733 From mbaesken at openjdk.org Mon Nov 24 08:30:07 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 24 Nov 2025 08:30:07 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> References: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> Message-ID: On Sun, 23 Nov 2025 22:53:45 GMT, Sergey Bylokhov wrote: > here is my finding, no issues were found by the tests: > > Platform / Compiler Before After Win (number) Win (%) > Windows, VS 2022 204 800 206 848 ?2 048 ?1.00% > macOS, Xcode 14.3.1 335 664 219 568 116 096 34.57% > macOS, Xcode 26 391 168 237 360 153 808 39.32% > gcc 13.3.0 307 936 219 344 88 592 28.77% > gcc 11.4.0 303 944 174 168 129 776 42.70% > gcc 11.5.0 295 280 177 360 117 920 39.93% Thanks for testing, the results look pretty good ! In case some older toolchain has issues with the lto , we could disable it for this toolchain for `BUILD_LIBSPLASHSCREEN` in a follow up; but so far no such toolchain has been observed. So can I go ahead with the integrate ? Or should we wait for some other OpenJDK vendor to test the PR ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3569489846 From erikj at openjdk.org Mon Nov 24 13:47:32 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 24 Nov 2025 13:47:32 GMT Subject: RFR: 8370438: Offer link time optimization support on library level [v10] In-Reply-To: References: <_Whdp13JzAcz3uydTQ5z2M2hbkFEnDasS4H4MrEReQU=.b49bdeed-a10a-4166-a435-5daa49db5af5@github.com> Message-ID: On Mon, 24 Nov 2025 08:26:27 GMT, Matthias Baesken wrote: > So can I go ahead with the integrate ? > Or should we wait for some other OpenJDK vendor to test the PR ? I think you are good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3570857541 From rriggs at openjdk.org Mon Nov 24 14:25:41 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 24 Nov 2025 14:25:41 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v10] In-Reply-To: <_VpQ_oPGP6BR3DP_ZfSDtevk2cwePjo95duU3NQloOk=.5d80b35b-fc4b-441d-8a0e-9e038047fff5@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> <_VpQ_oPGP6BR3DP_ZfSDtevk2cwePjo95duU3NQloOk=.5d80b35b-fc4b-441d-8a0e-9e038047fff5@github.com> Message-ID: On Fri, 21 Nov 2025 23:56:05 GMT, Xueming Shen wrote: >> ### Summary >> >> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. >> >> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: >> >> **String.equalsIgnoreCase(String)** >> >> - Unicode-aware, locale-independent. >> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. >> - Limited: does not support 1:M mapping defined in Unicode case folding. >> >> **Character.toLowerCase(int) / Character.toUpperCase(int)** >> >> - Locale-independent, single code point only. >> - No support for 1:M mappings. >> >> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** >> >> - Based on Unicode SpecialCasing.txt, supports 1:M mappings. >> - Intended primarily for presentation/display, not structural case-insensitive matching. >> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. >> >> **1:M mapping example, U+00DF (?)** >> >> - String.toUpperCase(Locale.ROOT, "?") ? "SS" >> - Case folding produces "ss", matching Unicode caseless comparison rules. >> >> >> jshell> "\u00df".equalsIgnoreCase("ss") >> $22 ==> false >> >> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") >> $24 ==> true >> >> >> ### Motivation & Direction >> >> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. >> >> - Unicode-compliant **full** case folding. >> - Simpler, stable and more efficient case-less matching without workarounds. >> - Brings Java's string comparison handling in line with other programming languages/libraries. >> >> This PR proposes to introduce the following comparison methods in `String` class >> >> - boolean equalsFoldCase(String anotherString) >> - int compareToFoldCase(String anotherString) >> - Comparator UNICODE_CASEFOLD_ORDER >> >> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. >> >> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. >> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > doc update - add spec tag Looks good, a couple of javadoc formatting changes would clean up the formatted javadoc. src/java.base/share/classes/java/lang/String.java line 2243: > 2241: * per-character mapping performed by {@code equalsIgnoreCase}. > 2242: * For example: > 2243: * 

{@snippet lang=java :


 and 
 are unnecessary, @snippet handles the formatting.

src/java.base/share/classes/java/lang/String.java line 2445:

> 2443:      * {@code compareToIgnoreCase}.
> 2444:      * For example:
> 2445:      * 
{@snippet lang=java :


 and 
 are redundant and should be removed.  @snippet handles all the formatting.

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

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3500569860
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2556436806
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2556430920

From azvegint at openjdk.org  Mon Nov 24 14:35:51 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 24 Nov 2025 14:35:51 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken  wrote:

>> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
>> But for other JDK native libs, we do not have support for this feature.
>> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add lto to EXTRA_FLAGS, not to OPT

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27976#pullrequestreview-3500730204

From rmarchenko at openjdk.org  Mon Nov 24 14:38:27 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Mon, 24 Nov 2025 14:38:27 GMT
Subject: RFR: 8372414: Command "make test-prebuilt" fails when listing tests
Message-ID: 

Restoring a line which, I think, was accidentally removed.

Now the command works OK:

$ JTREG_OPTIONS="-l" TEST=:tier1_part1 make test-prebuilt
...
Tests found: 1,095
Finished running test 'jtreg:test/jdk:tier1_part1'
Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_jdk_tier1_part1

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>> jtreg:test/jdk:tier1_part1                            1     0     0     1     0 <<
==============================
TEST FAILURE

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

Commit messages:
 - 8372414: make test-prebuilt fails when listing tests

Changes: https://git.openjdk.org/jdk/pull/28478/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28478&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372414
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28478/head:pull/28478

PR: https://git.openjdk.org/jdk/pull/28478

From mbaesken at openjdk.org  Mon Nov 24 14:53:33 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Nov 2025 14:53:33 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: 

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

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

  Set the -dead_strip linker option only for the JDK libs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28319/files
  - new: https://git.openjdk.org/jdk/pull/28319/files/b41966b8..b63b9ca8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=02-03

  Stats: 13 lines in 2 files changed: 2 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28319/head:pull/28319

PR: https://git.openjdk.org/jdk/pull/28319

From erikj at openjdk.org  Mon Nov 24 14:53:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 24 Nov 2025 14:53:45 GMT
Subject: RFR: 8372414: Command "make test-prebuilt" fails when listing
 tests
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Nov 2025 14:27:40 GMT, Roman Marchenko  wrote:

> Restoring a line which, I think, was accidentally removed.
> 
> Now the command works OK:
> 
> $ JTREG_OPTIONS="-l" TEST=:tier1_part1 make test-prebuilt
> ...
> Tests found: 1,095
> Finished running test 'jtreg:test/jdk:tier1_part1'
> Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_jdk_tier1_part1
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>> jtreg:test/jdk:tier1_part1                            1     0     0     1     0 <<
> ==============================
> TEST FAILURE

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28478#pullrequestreview-3500806998

From mbaesken at openjdk.org  Mon Nov 24 15:01:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Nov 2025 15:01:56 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
 
 
Message-ID: 

On Fri, 21 Nov 2025 08:27:51 GMT, Matthias Baesken  wrote:

> Maybe we should for now limit the dead_strip to the JDK native libs ?

Done; additionally I set the dead_strip flag only for release builds (for (fast)debug builds we most likely are totally fine with larger binaries and debuginfo files) .

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3571211348

From duke at openjdk.org  Mon Nov 24 21:23:19 2025
From: duke at openjdk.org (duke)
Date: Mon, 24 Nov 2025 21:23:19 GMT
Subject: RFR: 8372414: Command "make test-prebuilt" fails when listing
 tests
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Nov 2025 14:27:40 GMT, Roman Marchenko  wrote:

> Restoring a line which, I think, was accidentally removed.
> 
> Now the command works OK:
> 
> $ JTREG_OPTIONS="-l" TEST=:tier1_part1 make test-prebuilt
> ...
> Tests found: 1,095
> Finished running test 'jtreg:test/jdk:tier1_part1'
> Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_jdk_tier1_part1
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>> jtreg:test/jdk:tier1_part1                            1     0     0     1     0 <<
> ==============================
> TEST FAILURE

@wkia 
Your change (at version 05ab465509089fd2ebbb61af97b81c4ec750b52b) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28478#issuecomment-3572771791

From mbaesken at openjdk.org  Tue Nov 25 08:29:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 08:29:30 GMT
Subject: RFR: 8370438: Offer link time optimization support on library
 level [v10]
In-Reply-To: 
References: 
 
Message-ID: 

On Fri, 7 Nov 2025 15:06:51 GMT, Matthias Baesken  wrote:

>> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
>> But for other JDK native libs, we do not have support for this feature.
>> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add lto to EXTRA_FLAGS, not to OPT

Thanks the the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/27976#issuecomment-3574310327

From mbaesken at openjdk.org  Tue Nov 25 08:29:32 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 08:29:32 GMT
Subject: Integrated: 8370438: Offer link time optimization support on library
 level
In-Reply-To: 
References: 
Message-ID: 

On Fri, 24 Oct 2025 12:58:15 GMT, Matthias Baesken  wrote:

> We currently have support for LTO (link time optimization) for Hotspot/libjvm, that can be enabled as a JVM feature.
> But for other JDK native libs, we do not have support for this feature.
> LTO and sometimes lead to faster and also in some cases smaller binaries, so support for this might be interesting also for other libs and not only libjvm.

This pull request has now been integrated.

Changeset: 5ef2c9aa
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/5ef2c9aa09247f9853bf04db0df962fcff764499
Stats:     48 lines in 8 files changed: 34 ins; 11 del; 3 mod

8370438: Offer link time optimization support on library level

Reviewed-by: erikj, serb, azvegint

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

PR: https://git.openjdk.org/jdk/pull/27976

From mbaesken at openjdk.org  Tue Nov 25 09:08:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 09:08:30 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
Message-ID: 

On Mon, 24 Nov 2025 14:53:33 GMT, Matthias Baesken  wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the -dead_strip linker option only for the JDK libs

Any comments on the recent version ? 
The dead_strip option seems to the rather similar to the link time gc option we support for gcc currently and offer this configure flag 

make/autoconf/jdk-options.m4


112   UTIL_ARG_ENABLE(NAME: linktime-gc, DEFAULT: $LINKTIME_GC_DEFAULT,
113       DEFAULT_DESC: [auto], RESULT: ENABLE_LINKTIME_GC,
114       DESC: [use link time gc on unused code sections in the JDK build],
115       CHECKING_MSG: [if linker should clean out unused code (linktime-gc)])
116   AC_SUBST(ENABLE_LINKTIME_GC)



Should we also put the dead_strip behind this configure flag and rephrase the description above a little bit , e.g.
`114       DESC: [use link time gc or similar features on unused code sections in the JDK build],`

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3574548509

From mbaesken at openjdk.org  Tue Nov 25 09:26:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 09:26:11 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
Message-ID: 

On Mon, 24 Nov 2025 14:53:33 GMT, Matthias Baesken  wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the -dead_strip linker option only for the JDK libs

Here are some current values  (build from last evening 24th Nov.) for JDK native libs where I see a noticeable effect in size reduction with this PR (values in K without `->` with the flag , product build, XCode 15 used)

1216 ->  1188    /jdk/lib/libawt_lwawt.dylib
1348 ->  1036    /jdk/lib/libfontmanager.dylib
636	 ->  620     /jdk/lib/libfreetype.dylib
264  ->  248     /jdk/lib/libjavajpeg.dylib
312	 ->  292     /jdk/lib/libjdwp.dylib
152 -> 132       /jdk/lib/libjli.dylib
388 -> 296       /jdk/lib/liblcms.dylib
500 -> 484     /jdk/lib/libmlib_image.dylib
164 -> 128     /jdk/lib/libzip.dylib

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3574624069

From goetz at openjdk.org  Tue Nov 25 10:21:44 2025
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Tue, 25 Nov 2025 10:21:44 GMT
Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3]
In-Reply-To: 
References: 
 
Message-ID: <93M0copXchKBlrEoFUpnBjq9gC2Om_9poLUMB15ECiw=.ee14e2c6-dd31-4e1b-9662-f0d3048d4db7@github.com>

On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken  wrote:

>> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments.
>> See for example this manpage :
>> https://manpages.debian.org/testing/lld-7/ld.lld-7.1
>> 
>> 
>> sizes of libjvm.so with / without -icf=all
>> linux aarch64 : 25888 / 27112 K
>> linux x86_64 : 27952 / 29072 K
>> 
>> 
>> (for most other native libs the identical code folding has no effect, because there is nothing to fold)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit icf to release builds

LGTM

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

Marked as reviewed by goetz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28236#pullrequestreview-3504348002

From galder at openjdk.org  Tue Nov 25 11:33:00 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 25 Nov 2025 11:33:00 GMT
Subject: RFR: 8372393: Document requirement for separate metallib installation
 with Xcode 26.1.1
Message-ID: 

Document the metal toolchain requirements starting with Xcode 26.

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

Commit messages:
 - Document Metal installation with XCode 26

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

PR: https://git.openjdk.org/jdk/pull/28489

From jwaters at openjdk.org  Tue Nov 25 12:20:12 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Nov 2025 12:20:12 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v3]
In-Reply-To: 
References: 
Message-ID: 

> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated.
> 
> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer
> - -flto is set to $(JOBS) instead of auto to better match what the user requested
> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Revert recent changes to ClientLibraries.gmk
 - Revert recent changes to CompileJvm.gmk
 - Revert recent changes to Flags.gmk
 - Revert recent changes to NativeCompilation.gmk
 - Revert recent changes to spec.gmk.template
 - Revert recent changes to flags-ldflags.m4
 - Revert recent changes to flags-cflags.m4
 - Remove no longer needed warning disable in JvmFeatures.gmk
 - Merge branch 'master' into patch-16
 - Merge branch 'openjdk:master' into patch-16
 - ... and 11 more: https://git.openjdk.org/jdk/compare/34d6cc0d...9599d09e

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

Changes: https://git.openjdk.org/jdk/pull/22464/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=02
  Stats: 53 lines in 9 files changed: 11 ins; 38 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464

PR: https://git.openjdk.org/jdk/pull/22464

From mbaesken at openjdk.org  Tue Nov 25 13:00:32 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 13:00:32 GMT
Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken  wrote:

>> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments.
>> See for example this manpage :
>> https://manpages.debian.org/testing/lld-7/ld.lld-7.1
>> 
>> 
>> sizes of libjvm.so with / without -icf=all
>> linux aarch64 : 25888 / 27112 K
>> linux x86_64 : 27952 / 29072 K
>> 
>> 
>> (for most other native libs the identical code folding has no effect, because there is nothing to fold)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit icf to release builds

Thanks for the review !
Maybe someone from build-dev show review too ?

> (for most other native libs the identical code folding has no effect, because there is nothing to fold)

We could limit the usage of the flag to libjvm where it shows effect ; this would be similar to Windows , where we set a similar flag also only for jvm lib 
`BASIC_LDFLAGS_JVM_ONLY="-opt:icf,8 -subsystem:windows"`

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

PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3575519268

From mbaesken at openjdk.org  Tue Nov 25 13:12:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 13:12:06 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v5]
In-Reply-To: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
Message-ID: 

> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
> (before -> after setting the option)
> 
> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
> 152K -> 132K images/jdk/lib/libjli.dylib
> 388K -> 296K images/jdk/lib/liblcms.dylib
> 164K -> 128K images/jdk/lib/libzip.dylib
> 
> 
> and libjvm :
> 
> 20M -> 18M images/jdk/lib/server/libjvm.dylib
> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM

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

  Use dead_strip on macOS arrch64 AND x86_64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28319/files
  - new: https://git.openjdk.org/jdk/pull/28319/files/b63b9ca8..c158747f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28319&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28319/head:pull/28319

PR: https://git.openjdk.org/jdk/pull/28319

From mbaesken at openjdk.org  Tue Nov 25 13:12:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 25 Nov 2025 13:12:08 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v4]
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
Message-ID: <5_ovGdYHonxBCe-7ftDT2kErYBHe-8HPv0cwme_2Mj8=.1479051a-0fa5-455f-89c3-1312f2d16017@github.com>

On Mon, 24 Nov 2025 14:53:33 GMT, Matthias Baesken  wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set the -dead_strip linker option only for the JDK libs

Now we only set the flag for the JDK native libs, so I enabled it also for macOS x86_64 .

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3575562810

From rmarchenko at openjdk.org  Tue Nov 25 13:45:32 2025
From: rmarchenko at openjdk.org (Roman Marchenko)
Date: Tue, 25 Nov 2025 13:45:32 GMT
Subject: Integrated: 8372414: Command "make test-prebuilt" fails when listing
 tests
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Nov 2025 14:27:40 GMT, Roman Marchenko  wrote:

> Restoring a line which, I think, was accidentally removed.
> 
> Now the command works OK:
> 
> $ JTREG_OPTIONS="-l" TEST=:tier1_part1 make test-prebuilt
> ...
> Tests found: 1,095
> Finished running test 'jtreg:test/jdk:tier1_part1'
> Test report is stored in build/run-test-prebuilt/test-results/jtreg_test_jdk_tier1_part1
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR  SKIP
>>> jtreg:test/jdk:tier1_part1                            1     0     0     1     0 <<
> ==============================
> TEST FAILURE

This pull request has now been integrated.

Changeset: c00d29af
Author:    Roman Marchenko 
Committer: Erik Joelsson 
URL:       https://git.openjdk.org/jdk/commit/c00d29afa9c3de65b1ca4e98dbb9e6f6931d7437
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8372414: Command "make test-prebuilt" fails when listing tests

Reviewed-by: erikj

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

PR: https://git.openjdk.org/jdk/pull/28478

From erikj at openjdk.org  Tue Nov 25 14:00:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Nov 2025 14:00:45 GMT
Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken  wrote:

>> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments.
>> See for example this manpage :
>> https://manpages.debian.org/testing/lld-7/ld.lld-7.1
>> 
>> 
>> sizes of libjvm.so with / without -icf=all
>> linux aarch64 : 25888 / 27112 K
>> linux x86_64 : 27952 / 29072 K
>> 
>> 
>> (for most other native libs the identical code folding has no effect, because there is nothing to fold)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit icf to release builds

If hotspot is ok with this, then it looks fine to me.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28236#pullrequestreview-3505209965

From erikj at openjdk.org  Tue Nov 25 14:00:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Nov 2025 14:00:45 GMT
Subject: RFR: 8372393: Document requirement for separate metallib
 installation with Xcode 26.1.1
In-Reply-To: 
References: 
Message-ID: 

On Tue, 25 Nov 2025 11:25:59 GMT, Galder Zamarre?o  wrote:

> Document the metal toolchain requirements starting with Xcode 26.

doc/building.html line 547:

> 545: comes bundled with Xcode, so it needs to be installed separately. This can
> 546: either be done via the Xcode's Settings/Components UI, or in the command line
> 547: calling xcodebuild -downloadComponent metalToolchain.


When I checkout this branch and run `make update-build-docs`, the line breaks here are done differently. It would be good to not introduce future diffs when the html files are regenerated next time.

Suggestion:


Starting with Xcode 26, introduced in macOS 26, the Metal toolchain
no longer comes bundled with Xcode, so it needs to be installed
separately. This can either be done via the Xcode's Settings/Components
UI, or in the command line calling
xcodebuild -downloadComponent metalToolchain.


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

PR Review Comment: https://git.openjdk.org/jdk/pull/28489#discussion_r2560088391

From weijun at openjdk.org  Tue Nov 25 14:03:29 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 25 Nov 2025 14:03:29 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall  wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up jtreg run/compile directives, attend to other review comments

Maybe this is because the native library always exists on Windows and Mac, therefore an `UnsatisfiedLinkError` is never thrown there. For Linux where it could be missing, we should catch the error and gracefully fallback.

I still think this should be mandatory at compile-time. You may define `--enable-xyz` or `--with-xyz` configure options.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3575799283

From erikj at openjdk.org  Tue Nov 25 14:03:31 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Nov 2025 14:03:31 GMT
Subject: RFR: 8371893: [macOS aarch64] use dead_strip linker option to
 reduce binary size [v5]
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
Message-ID: 

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken  wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28319#pullrequestreview-3505215274

From erikj at openjdk.org  Tue Nov 25 16:33:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Nov 2025 16:33:39 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: 
References: 
 
 
Message-ID: <6j9tRXkOVMsEinjuv9JGhCbDlFbgq44nJD2Et_0c8lE=.0617bf53-de39-44cb-8a2a-bef390ba4a8b@github.com>

On Tue, 25 Nov 2025 14:00:53 GMT, Weijun Wang  wrote:

> I still think this should be mandatory at compile-time. You may define `--enable-xyz` or `--with-xyz` configure options.

@wangweij Making this mandatory at compile time will require some effort to keep builds at Oracle working, as I described earlier. Are you prepared to do that?

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3576515465

From erikj at openjdk.org  Tue Nov 25 17:47:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Nov 2025 17:47:36 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: 
References: 
 
Message-ID: <74cdaBT7wW3NTCq3RSmzNiP_KMizx2CzENZfRTd7vKk=.cb89c03b-4a1e-4619-a381-4b73804f716c@github.com>

On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall  wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up jtreg run/compile directives, attend to other review comments

A 3rd party dependency in the build needs to be documented in building.md.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3576806505

From sherman at openjdk.org  Tue Nov 25 20:21:26 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 25 Nov 2025 20:21:26 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: 

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> See CSR https://bugs.openjd...

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

  minor doc formatting update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/0aafb674..e5da752f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=09-10

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27628.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27628/head:pull/27628

PR: https://git.openjdk.org/jdk/pull/27628

From rriggs at openjdk.org  Tue Nov 25 21:13:15 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 21:13:15 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
Message-ID: <-caDaiJwJQ_T1kM5_TjsEe8HsNj40wfIparhZaLfZa4=.8c0248ea-04e7-42d3-bb7f-0f811d8d2813@github.com>

On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen  wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor doc formatting update

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3506820703

From rriggs at openjdk.org  Tue Nov 25 21:31:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 21:31:38 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 
Message-ID: 

On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen  wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor doc formatting update

Try again for information on the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3577662129

From weijun at openjdk.org  Wed Nov 26 01:02:56 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 26 Nov 2025 01:02:56 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall  wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up jtreg run/compile directives, attend to other review comments

After some offline discussion, I'm now OK with making this an optional feature at build time.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3578281909

From duke at openjdk.org  Wed Nov 26 09:36:13 2025
From: duke at openjdk.org (Nick Hall)
Date: Wed, 26 Nov 2025 09:36:13 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: 
References: 
 
Message-ID: <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>

On Tue, 18 Nov 2025 12:21:09 GMT, Nick Hall  wrote:

>> _Purpose_
>> 
>> This PR allows Linux based applications using JAAS to acquire Kerberos TGTs natively using the local system's Kerberos libraries/configuration, building on existing support on Windows/MacOSX.
>> 
>> _Rationale_
>> 
>> Currently the (pure java) JAAS codebase only supports file-based credential caches (ccaches).  There are many other useful types of ccache accessible via the local system libraries; this change allows credentials to be acquired natively using those libraries, and thus adds support for all other ccache types supported by the local system (e.g. KCM, in-memory and kernel types),  This support already exists on MacOSX and Windows.
>> 
>> The code change here largely uses the MacOSX code, edited for Linux with associated build system changes. It also adds an appropriate jtreg test which uses some native test helper code to manufacture an in-memory cache, and then uses the new code to acquire these credentials natively.  This has been tested on Linux/Mac and the jtreg test passes on each (I couldn't see any existing tests on MacOSX for this feature).
>> 
>> Additionally this PR fixes a bug that's existed for a while (see L585-588 in `nativeccache.c`) - without this code, this is a 100% reproducible segfault on Linux (it's unclear why this hasn't affected the Mac JVMs up to now, probably just no calling code that provides an empty list of addresses).  It also fixes a (non problem) typo in the variable name in a function prototype.
>> 
>> _Implementation Detail_
>> 
>> Note that there were multiple possible ways of doing this:
>> 
>> 1) Duplicate the MacOSX `nativeccache.c`, edit lightly for Linux and build a new library on Linux only (`liblinuxkrb5`), leaving MacOSX largely unchanged, but at the expense of this code duplication.
>> 
>> 2) Create a new shared library used on both platforms with conditional compilation to manage the differences.  This necessitates a library name change on MacOSX and potentially knock-on packaging changes on that platform, which seemed a potentially expensive side-effect.
>> 
>> 3) Create a shared `nativeccache.c` (using `EXTRA_SRC` in the build) and build separate MacOSX/Linux libraries.  This allows the MacOSX library name to remain unchanged, and only adds a new library in Linux.
>> 
>> I tried all three options; 3 seemed to be the best compromise all around, although is one of the options that effectively introduces a "no-op" change on MacOSX as a result.  Hopefully the additional jtreg test is sufficient to compensat...
>
> Nick Hall has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up jtreg run/compile directives, attend to other review comments

Apologies for the slow response on this!

> Maybe this is because the native library always exists on Windows and Mac, therefore an UnsatisfiedLinkError is never thrown there. For Linux where it could be missing, we should catch the error and gracefully fallback.

Most likely this is how things got to the current state, yes.  I think it might actually be advantageous in this case to build the JVM with krb5 compiled in, catch any link errors that happen because the runtime system doesn't have the Kerberos libraries and silently failback to the previous behaviour on Linux only, preserving the existing behaviour on Windows/Mac, where the library _should_ be there, and therefore a link error is a real failure.

> After some offline discussion, I'm now OK with making this an optional feature at build time.

I think the only downside of this is that distributions might not build it in - meaning that people who want this would have to resort to compiling their own JVM (which some corporates, where this is most likely to be useful, might not allow - e.g. those that get their Java from RH/Canonical etc under a support agreement) or lobby their upstream provider, which isn't always particularly fruitful...

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3580434455

From mbaesken at openjdk.org  Wed Nov 26 10:08:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Nov 2025 10:08:54 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
Message-ID: 

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken  wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

For macOS x86_64 it works too at least for some of the libs. See the size without and with dead_strip 


1200 -> 1164    /jdk/lib/libawt_lwawt.dylib
1364 -> 1048    /jdk/lib/libfontmanager.dylib
636  -> 632     /jdk/lib/libfreetype.dylib
240  -> 236     /jdk/lib/libjavajpeg.dylib
280  -> 276     jdk/lib/libjdwp.dylib
92   -> 92      /jdk/lib/libjli.dylib
428  -> 320     /jdk/lib/liblcms.dylib
716  -> 688     /jdk/lib/libmlib_image.dylib
60   -> 60      /jdk/lib/libzip.dylib


For some strange reasons, it does not help on libzip and libjli .
But those are smaller anyway compared to aarch64.  (it is a bit surprising that libzip is twice as large on aarch64 !)

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3580564402

From serb at openjdk.org  Wed Nov 26 11:03:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 26 Nov 2025 11:03:49 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
Message-ID: <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken  wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

I'll run UI the tests for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3580783766

From mbaesken at openjdk.org  Wed Nov 26 11:20:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Nov 2025 11:20:52 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
 <5xGU22WgiZiCJGUU3G3e1-SAty0aXnjzEbj3nx30y5c=.337ef8d2-e79e-477f-916c-a344079370a9@github.com>
Message-ID: 

On Wed, 26 Nov 2025 11:01:22 GMT, Sergey Bylokhov  wrote:

> I'll run UI the tests for this.

Great, thanks !

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

PR Comment: https://git.openjdk.org/jdk/pull/28319#issuecomment-3580838458

From lucy at openjdk.org  Wed Nov 26 12:42:56 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 26 Nov 2025 12:42:56 GMT
Subject: RFR: 8371893: [macOS] use dead_strip linker option to reduce
 binary size [v5]
In-Reply-To: 
References: <5GKe55IFkJgBmku-Y-X4mcoy0V43x-ZXBzwb7EbwqTU=.23fe4819-b951-4364-a7b5-315e2b6d5824@github.com>
 
Message-ID: 

On Tue, 25 Nov 2025 13:12:06 GMT, Matthias Baesken  wrote:

>> The dead_strip linker option on macOS removes functions and data that are unreachable by the entry point or exported symbols.
>> Setting it can reduce the size of some binaries we generate quite a lot, for example (product build, Xcode 15 is used) :
>> (before -> after setting the option)
>> 
>> 1.4M -> 1.1M images/jdk/lib/libfontmanager.dylib
>> 264K -> 248K images/jdk/lib/libjavajpeg.dylib
>> 152K -> 132K images/jdk/lib/libjli.dylib
>> 388K -> 296K images/jdk/lib/liblcms.dylib
>> 164K -> 128K images/jdk/lib/libzip.dylib
>> 
>> 
>> and libjvm :
>> 
>> 20M -> 18M images/jdk/lib/server/libjvm.dylib
>> 146M -> 137M images/jdk/lib/server/libjvm.dylib.dSYM
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use dead_strip on macOS arrch64 AND x86_64

Looks good, finally. 
Lots of discussion for such a tiny change... :-)

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28319#pullrequestreview-3510772202

From mbaesken at openjdk.org  Wed Nov 26 12:53:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Nov 2025 12:53:03 GMT
Subject: Integrated: 8371626: [linux] use icf=all for linking libraries
In-Reply-To: 
References: 
Message-ID: 

On Tue, 11 Nov 2025 14:27:53 GMT, Matthias Baesken  wrote:

> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments.
> See for example this manpage :
> https://manpages.debian.org/testing/lld-7/ld.lld-7.1
> 
> 
> sizes of libjvm.so with / without -icf=all
> linux aarch64 : 25888 / 27112 K
> linux x86_64 : 27952 / 29072 K
> 
> 
> (for most other native libs the identical code folding has no effect, because there is nothing to fold)

This pull request has now been integrated.

Changeset: 4ae2f31f
Author:    Matthias Baesken 
URL:       https://git.openjdk.org/jdk/commit/4ae2f31f3d2027daa0a5ccba6180e7bb27413aa5
Stats:     8 lines in 2 files changed: 8 ins; 0 del; 0 mod

8371626: [linux] use icf=all for linking libraries

Reviewed-by: goetz, erikj

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

PR: https://git.openjdk.org/jdk/pull/28236

From mbaesken at openjdk.org  Wed Nov 26 12:53:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 26 Nov 2025 12:53:01 GMT
Subject: RFR: 8371626: [linux] use icf=all for linking libraries [v3]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 12 Nov 2025 15:46:09 GMT, Matthias Baesken  wrote:

>> Identical code folding can reduce the size of some libs, especially libjvm. However not all linkers support the flag/feature so we have to limit it to some environments.
>> See for example this manpage :
>> https://manpages.debian.org/testing/lld-7/ld.lld-7.1
>> 
>> 
>> sizes of libjvm.so with / without -icf=all
>> linux aarch64 : 25888 / 27112 K
>> linux x86_64 : 27952 / 29072 K
>> 
>> 
>> (for most other native libs the identical code folding has no effect, because there is nothing to fold)
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Limit icf to release builds

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/28236#issuecomment-3581179600

From erikj at openjdk.org  Wed Nov 26 14:12:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 26 Nov 2025 14:12:13 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>
References: 
 
 <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>
Message-ID: 

On Wed, 26 Nov 2025 09:33:26 GMT, Nick Hall  wrote:

> > After some offline discussion, I'm now OK with making this an optional feature at build time.
> 
> I think the only downside of this is that distributions might not build it in - meaning that people who want this would have to resort to compiling their own JVM (which some corporates, where this is most likely to be useful, might not allow - e.g. those that get their Java from RH/Canonical etc under a support agreement) or lobby their upstream provider, which isn't always particularly fruitful...

If you want to drive adoption, or even think about making this mandatory at build time, then at the very least you need to make sure the devkits produced by the makefiles under `make/devkit/...` contain the necessary build time dependencies and generally work with this feature. At least at Oracle we rely on these for our builds and my impression is that at least some other vendors do too.

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3581491313

From nbenalla at openjdk.org  Thu Nov 27 00:08:17 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 00:08:17 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Get JDK 27 underway.

Nizar Benalla 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 12 additional commits since the last revision:

 - Update --release 26 symbol information for JDK 26 build 25
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
 - revert MAX_COLUMNS to 80
 - Update LATEST_MAJOR_VERSION in Versions.java
 - Merge branch 'master' into start-of-release-27
 - Merge branch 'master' into start-of-release-27
 - Merge branch 'master' into start-of-release-27
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Merge branch 'master' into start-of-release-27
 - update links to JVMS 26 and 27
 - ... and 2 more: https://git.openjdk.org/jdk/compare/53a97205...78895b2b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/3d9eb308..78895b2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=04-05

  Stats: 69573 lines in 1019 files changed: 46890 ins; 15885 del; 6798 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

PR: https://git.openjdk.org/jdk/pull/28130

From nbenalla at openjdk.org  Thu Nov 27 00:27:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 00:27:50 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 27 Nov 2025 00:08:17 GMT, Nizar Benalla  wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla 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 12 additional commits since the last revision:
> 
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4bfba094...78895b2b

I had to make some changes to respect the 80 character limit we used to have.
Instead of showing a long list for the --release values in the javac help output we show the following:

  --target , -target 
        Generate class files suitable for the specified Java SE release.
        Supported releases: 
            8, 9, 10, ..., 25, 26, 27

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

PR Comment: https://git.openjdk.org/jdk/pull/28130#issuecomment-3583630744

From iris at openjdk.org  Thu Nov 27 00:37:53 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Nov 2025 00:37:53 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: 
References: 
 
Message-ID: <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>

On Thu, 27 Nov 2025 00:08:17 GMT, Nizar Benalla  wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla 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 12 additional commits since the last revision:
> 
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a52f9076...78895b2b

The changes in com.sun.tools.javac.main.Option don't appear strictly necessary for the start of release updates...

test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:

> 48: public class HelpOutputColumnWidthTest extends TestRunner {
> 49: 
> 50:     public static final int MAX_COLUMNS = 80;

I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3513096801
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566785560

From iris at openjdk.org  Thu Nov 27 00:37:54 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Nov 2025 00:37:54 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
References: 
 
 <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
Message-ID: 

On Thu, 27 Nov 2025 00:31:23 GMT, Iris Clark  wrote:

>> Nizar Benalla 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 12 additional commits since the last revision:
>> 
>>  - Update --release 26 symbol information for JDK 26 build 25
>>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>>  - revert MAX_COLUMNS to 80
>>  - Update LATEST_MAJOR_VERSION in Versions.java
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>>  - Merge branch 'master' into start-of-release-27
>>  - update links to JVMS 26 and 27
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a52f9076...78895b2b
>
> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
> 
>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>> 49: 
>> 50:     public static final int MAX_COLUMNS = 80;
> 
> I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.

oops.. that should have been `80x24`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566789434

From jdv at openjdk.org  Thu Nov 27 01:19:29 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 27 Nov 2025 01:19:29 GMT
Subject: RFR: 8372534: Update Libpng to 1.6.51
Message-ID: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>

Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version.

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

Commit messages:
 - Update
 - update .md file
 - 8372534: Update Libpng to 1.6.51

Changes: https://git.openjdk.org/jdk/pull/28518/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28518&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372534
  Stats: 638 lines in 21 files changed: 297 ins; 207 del; 134 mod
  Patch: https://git.openjdk.org/jdk/pull/28518.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28518/head:pull/28518

PR: https://git.openjdk.org/jdk/pull/28518

From serb at openjdk.org  Thu Nov 27 01:51:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Nov 2025 01:51:52 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: 
References: 
 
 
 
Message-ID: 

On Mon, 24 Nov 2025 07:59:24 GMT, Julian Waters  wrote:

>gcc documentation states that you typically need to pass the same options to the link step from the compile step, since the linker when LTO is active is actually the compiler in disguise.

So it seems a pre-existing bug which affects the old jdk updates as well? probably we can extract that change and fix it separately and then backport? or do you plan to backport this one?

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3583903828

From jdv at openjdk.org  Thu Nov 27 02:17:47 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 27 Nov 2025 02:17:47 GMT
Subject: RFR: 8372534: Update Libpng to 1.6.51
In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
Message-ID: 

On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V  wrote:

> Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version.

make/modules/java.desktop/lib/ClientLibraries.gmk line 240:

> 238:       DISABLED_WARNINGS_gcc_jcmaster.c := implicit-fallthrough, \
> 239:       DISABLED_WARNINGS_gcc_jdphuff.c := shift-negative-value, \
> 240:       DISABLED_WARNINGS_gcc_png.c := maybe-uninitialized, \

These warnings were disabled in previous libpng update because of https://github.com/openjdk/jdk/pull/24021/files#r1993813117

We have appropriate update in upstream and we are not facing the build issue, so the code change is reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28518#discussion_r2566971834

From nbenalla at openjdk.org  Thu Nov 27 02:25:47 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 02:25:47 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: 
References: 
 
 <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
 
Message-ID: 

On Thu, 27 Nov 2025 00:35:11 GMT, Iris Clark  wrote:

>> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
>> 
>>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>>> 49: 
>>> 50:     public static final int MAX_COLUMNS = 80;
>> 
>> I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.
>
> oops.. that should have been `80x24`.

I should have included more [context](https://github.com/openjdk/jdk/pull/25008#discussion_r2071880549).
The default width was increased to 84 in the last start of release update, I reverted it back to the original value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566979887

From jwaters at openjdk.org  Thu Nov 27 04:26:51 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 27 Nov 2025 04:26:51 GMT
Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2]
In-Reply-To: 
References: 
 
 
 
 
Message-ID: 

On Thu, 27 Nov 2025 01:49:07 GMT, Sergey Bylokhov  wrote:

> > gcc documentation states that you typically need to pass the same options to the link step from the compile step, since the linker when LTO is active is actually the compiler in disguise.
> 
> So it seems a pre-existing bug which affects the old jdk updates as well? probably we can extract that change and fix it separately and then backport? or do you plan to backport this one?

Hmm, I didn't create this with the idea of backporting it in mind. Should I do that?

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

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-3584144134

From galder at openjdk.org  Thu Nov 27 10:43:48 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 27 Nov 2025 10:43:48 GMT
Subject: RFR: 8372393: Document requirement for separate metallib
 installation with Xcode 26.1.1
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 Nov 2025 13:56:34 GMT, Erik Joelsson  wrote:

>> Document the metal toolchain requirements starting with Xcode 26.
>
> doc/building.html line 547:
> 
>> 545: comes bundled with Xcode, so it needs to be installed separately. This can
>> 546: either be done via the Xcode's Settings/Components UI, or in the command line
>> 547: calling xcodebuild -downloadComponent metalToolchain.

> 
> When I checkout this branch and run `make update-build-docs`, the line breaks here are done differently. It would be good to not introduce future diffs when the html files are regenerated next time.
> 
> Suggestion:
> 
> 
Starting with Xcode 26, introduced in macOS 26, the Metal toolchain
> no longer comes bundled with Xcode, so it needs to be installed
> separately. This can either be done via the Xcode's Settings/Components
> UI, or in the command line calling
> xcodebuild -downloadComponent metalToolchain.


Aha, I was not aware of that make target. I'll execute and update

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28489#discussion_r2568012748

From galder at openjdk.org  Thu Nov 27 11:04:29 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 27 Nov 2025 11:04:29 GMT
Subject: RFR: 8372393: Document requirement for separate metallib
 installation with Xcode 26.1.1 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Document the metal toolchain requirements starting with Xcode 26.

Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:

  Fix line breaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28489/files
  - new: https://git.openjdk.org/jdk/pull/28489/files/c9101083..427758b2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28489&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28489&range=00-01

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28489.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28489/head:pull/28489

PR: https://git.openjdk.org/jdk/pull/28489

From galder at openjdk.org  Thu Nov 27 11:04:31 2025
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 27 Nov 2025 11:04:31 GMT
Subject: RFR: 8372393: Document requirement for separate metallib
 installation with Xcode 26.1.1 [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Tue, 25 Nov 2025 13:56:34 GMT, Erik Joelsson  wrote:

>> Galder Zamarre?o has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix line breaks
>
> doc/building.html line 547:
> 
>> 545: comes bundled with Xcode, so it needs to be installed separately. This can
>> 546: either be done via the Xcode's Settings/Components UI, or in the command line
>> 547: calling xcodebuild -downloadComponent metalToolchain.

> 
> When I checkout this branch and run `make update-build-docs`, the line breaks here are done differently. It would be good to not introduce future diffs when the html files are regenerated next time.
> 
> Suggestion:
> 
> 
Starting with Xcode 26, introduced in macOS 26, the Metal toolchain
> no longer comes bundled with Xcode, so it needs to be installed
> separately. This can either be done via the Xcode's Settings/Components
> UI, or in the command line calling
> xcodebuild -downloadComponent metalToolchain.


@erikj79 Ran the target and pushed the changes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28489#discussion_r2568089159

From galder at ibm.com  Thu Nov 27 12:20:08 2025
From: galder at ibm.com (Galder Zamarreno)
Date: Thu, 27 Nov 2025 12:20:08 +0000
Subject: Mac devkit requires changes for XCode 26
Message-ID: 

Hi,

I'm wondering what's the objective of the Mac devkit and how much is it
being kept up to date.

I've been finding it useful to create a devkit that works for me to
build the jdk inside a Nix shell on a mac. Nix shells easily allow me to
capture all the dependencies building jdks have (e.g. capstone) in a
reproducable way independent of global installations at the mac level.

With the latest XCode 26 and Metal separation, I've been finding that
the current mac devkit is not fully suited for this changes.

As you might have seen in [1], Metal is no longer part of XCode 26 and
now needs to be installed separately. The location where Metal gets
installed by default is not inside /Applications/XCode.app but a rather
different place. On my system this is:

```
% xcrun --find metallib
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.2.54.0.mgWMUd/Metal.xctoolchain/usr/bin/metallib
```

To be able to carry on building the JDK on a Nix shell, I manually moved
the Metal.xctoolchain folder to
/Applications/Xcode.app/Contents/Developer/Toolchains and then invoked
the mac devkit script.

This alone however was not enough to get the jdk to build, but the XCode
26 itself does have the `metal` executable and the jdk was picking it
up. So, on top of that manual move, I tweaked the
`DEVKIT_TOOLCHAIN_PATH` so that the Metal binaries would resolve out of
the Metal.xctoolchain/usr/bin folder:

```
echo-info "DEVKIT_TOOLCHAIN_PATH=\"\$DEVKIT_ROOT/Xcode/Contents/Developer/Toolchains/Metal.xctoolchain/usr/bin:\$DEVKIT_ROOT/Xcode/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:\$DEVKIT_ROOT/Xcode/Contents/Developer/usr/bin\""
```

After doing this I rebuilt the devkit and I was able to build the jdk
once again inside a Nix shell on mac.

Of course, the devkit could have been modified to avoid the need for the
manual move and instead resolve the `/var/run/...` folder. But I do
wonder how much this devkit really is kept up to date and what's the use
case that ended up creating it.

Thanks
Galder

[1] https://bugs.openjdk.org/browse/JDK-8372393
[2] https://medium.com/%40sergey-pekar/how-to-fix-annoying-xcode-26-not-building-swiftui-previews-error-cannot-execute-tool-metal-due-49564e20357c
--
Galder Zamarre?o
Software Developer
IBM Software
galder at ibm.com

IBM

From shade at openjdk.org  Thu Nov 27 17:28:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 27 Nov 2025 17:28:18 GMT
Subject: RFR: 8372188: AArch64: Generate atomic match rules from M4
 stencils
In-Reply-To: 
References: 
Message-ID: <2aGnPLAQsGhPyB6N1QwxvoI2tuzRcZhg93DH-BXCNmk=.ddb99506-85da-45c0-837e-798a5101cafe@github.com>

On Thu, 27 Nov 2025 14:54:06 GMT, Aleksey Shipilev  wrote:

> Current atomic match rules are all over the place in AArch64:
>  - CAE and weak CAS rules are generated with the help of `cas.m4`, and then are supposed to be copy-pasted (?) into `aarch64.ad`. I did it about 20 times when fixing [JDK-8372154](https://bugs.openjdk.org/browse/JDK-8372154), gets tedious very quickly.
>  - Strong CAS and get-and-set rules are still in the same section of `aarch64.ad`, and are written by hand. Yet, those can be automatically generated from M4 stencils as well.
> 
> This PR cleans that up by moving all these rules into a separate `.ad` file, which one can cleanly re-generate by invoking `m4 aarch64_atomic_ad.m4 > aarch64_atomic.ad`. The meat of the change is `aarch64_atomic.m4`, everything else is either generated from it, or removed in favor of auto-generated code. There should be no semantic change, as I attempted to move the rules mostly verbatim, only changing non-semantic stuff like match rule names and some formats.
> 
> Testing:
>  - [x] Eyeballing match rules before/after
>  - [x] Linux AArch64 server fastdebug, `hotspot_compiler`
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, jcstress run

Sanity checking with:


$ git diff master | grep ^- | grep instruct | grep "%{" | grep -v \$ | sort | nl
...
$ git diff master | grep ^+ | grep instruct | grep "%{" | grep -v \$ | sort | nl
...


60 match rules out, 60 match rules in.

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

PR Comment: https://git.openjdk.org/jdk/pull/28538#issuecomment-3586352646

From shade at openjdk.org  Thu Nov 27 17:28:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 27 Nov 2025 17:28:18 GMT
Subject: RFR: 8372188: AArch64: Generate atomic match rules from M4 stencils
Message-ID: 

Current atomic match rules are all over the place in AArch64:
 - CAE and weak CAS rules are generated with the help of `cas.m4`, and then are supposed to be copy-pasted (?) into `aarch64.ad`. I did it about 20 times when fixing [JDK-8372154](https://bugs.openjdk.org/browse/JDK-8372154), gets tedious very quickly.
 - Strong CAS and get-and-set rules are still in the same section of `aarch64.ad`, and are written by hand. Yet, those can be automatically generated from M4 stencils as well.

This PR cleans that up by moving all these rules into a separate `.ad` file, which one can cleanly re-generate by invoking `m4 aarch64_atomic_ad.m4 > aarch64_atomic.ad`. The meat of the change is `aarch64_atomic.m4`, everything else is either generated from it, or removed in favor of auto-generated code. There should be no semantic change, as I attempted to move the rules mostly verbatim, only changing non-semantic stuff like match rule names and some formats.

Testing:
 - [x] Eyeballing match rules before/after
 - [x] Linux AArch64 server fastdebug, `hotspot_compiler`
 - [x] Linux AArch64 server fastdebug, `tier1`
 - [ ] Linux AArch64 server fastdebug, `all`
 - [ ] Linux AArch64 server fastdebug, jcstress run

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

Commit messages:
 - More Hotspot tests do not like OptoAssembly changes
 - Some tests want specific formats + moves
 - Minor stencil touchup
 - Missed L_Acq variants
 - No more atomics in main AD
 - Fix

Changes: https://git.openjdk.org/jdk/pull/28538/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28538&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372188
  Stats: 2349 lines in 5 files changed: 1156 ins; 1193 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28538/head:pull/28538

PR: https://git.openjdk.org/jdk/pull/28538

From aph at openjdk.org  Thu Nov 27 17:41:47 2025
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 27 Nov 2025 17:41:47 GMT
Subject: RFR: 8372188: AArch64: Generate atomic match rules from M4
 stencils
In-Reply-To: 
References: 
Message-ID: 

On Thu, 27 Nov 2025 14:54:06 GMT, Aleksey Shipilev  wrote:

> Current atomic match rules are all over the place in AArch64:
>  - CAE and weak CAS rules are generated with the help of `cas.m4`, and then are supposed to be copy-pasted (?) into `aarch64.ad`. I did it about 20 times when fixing [JDK-8372154](https://bugs.openjdk.org/browse/JDK-8372154), gets tedious very quickly.
>  - Strong CAS and get-and-set rules are still in the same section of `aarch64.ad`, and are written by hand. Yet, those can be automatically generated from M4 stencils as well.
> 
> This PR cleans that up by moving all these rules into a separate `.ad` file, which one can cleanly re-generate by invoking `m4 aarch64_atomic_ad.m4 > aarch64_atomic.ad`. The meat of the change is `aarch64_atomic.m4`, everything else is either generated from it, or removed in favor of auto-generated code. There should be no semantic change, as I attempted to move the rules mostly verbatim, only changing non-semantic stuff like match rule names and some formats.
> 
> Testing:
>  - [x] Eyeballing match rules before/after
>  - [x] Linux AArch64 server fastdebug, `hotspot_compiler`
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, jcstress run

Thanks, that's a very nice cleanup.

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

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28538#pullrequestreview-3516508246

From serb at openjdk.org  Thu Nov 27 21:54:45 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 27 Nov 2025 21:54:45 GMT
Subject: RFR: 8372534: Update Libpng to 1.6.51
In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
Message-ID: 

On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V  wrote:

> Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28518#pullrequestreview-3516983381

From haosun at openjdk.org  Fri Nov 28 02:41:54 2025
From: haosun at openjdk.org (Hao Sun)
Date: Fri, 28 Nov 2025 02:41:54 GMT
Subject: RFR: 8372188: AArch64: Generate atomic match rules from M4
 stencils
In-Reply-To: 
References: 
Message-ID: 

On Thu, 27 Nov 2025 14:54:06 GMT, Aleksey Shipilev  wrote:

> Current atomic match rules are all over the place in AArch64:
>  - CAE and weak CAS rules are generated with the help of `cas.m4`, and then are supposed to be copy-pasted (?) into `aarch64.ad`. I did it about 20 times when fixing [JDK-8372154](https://bugs.openjdk.org/browse/JDK-8372154), gets tedious very quickly.
>  - Strong CAS and get-and-set rules are still in the same section of `aarch64.ad`, and are written by hand. Yet, those can be automatically generated from M4 stencils as well.
> 
> This PR cleans that up by moving all these rules into a separate `.ad` file, which one can cleanly re-generate by invoking `m4 aarch64_atomic_ad.m4 > aarch64_atomic.ad`. The meat of the change is `aarch64_atomic.m4`, everything else is either generated from it, or removed in favor of auto-generated code. There should be no semantic change, as I attempted to move the rules mostly verbatim, only changing non-semantic stuff like match rule names and some formats.
> 
> Testing:
>  - [x] Eyeballing match rules before/after
>  - [x] Linux AArch64 server fastdebug, `hotspot_compiler`
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [ ] Linux AArch64 server fastdebug, `all`
>  - [ ] Linux AArch64 server fastdebug, jcstress run

LGTM. Thanks for your work.

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

Marked as reviewed by haosun (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28538#pullrequestreview-3517305576

From azvegint at openjdk.org  Fri Nov 28 06:08:53 2025
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 28 Nov 2025 06:08:53 GMT
Subject: RFR: 8372534: Update Libpng to 1.6.51
In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
Message-ID: 

On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V  wrote:

> Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28518#pullrequestreview-3517579285

From shade at openjdk.org  Fri Nov 28 10:53:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Nov 2025 10:53:55 GMT
Subject: RFR: 8372188: AArch64: Generate atomic match rules from M4
 stencils
In-Reply-To: 
References: 
Message-ID: 

On Thu, 27 Nov 2025 14:54:06 GMT, Aleksey Shipilev  wrote:

> Current atomic match rules are all over the place in AArch64:
>  - CAE and weak CAS rules are generated with the help of `cas.m4`, and then are supposed to be copy-pasted (?) into `aarch64.ad`. I did it about 20 times when fixing [JDK-8372154](https://bugs.openjdk.org/browse/JDK-8372154), gets tedious very quickly.
>  - Strong CAS and get-and-set rules are still in the same section of `aarch64.ad`, and are written by hand. Yet, those can be automatically generated from M4 stencils as well.
> 
> This PR cleans that up by moving all these rules into a separate `.ad` file, which one can cleanly re-generate by invoking `m4 aarch64_atomic_ad.m4 > aarch64_atomic.ad`. The meat of the change is `aarch64_atomic.m4`, everything else is either generated from it, or removed in favor of auto-generated code. There should be no semantic change, as I attempted to move the rules mostly verbatim, only changing non-semantic stuff like match rule names and some formats.
> 
> Testing:
>  - [x] Eyeballing match rules before/after
>  - [x] Linux AArch64 server fastdebug, `hotspot_compiler`
>  - [x] Linux AArch64 server fastdebug, `tier1`
>  - [x] Linux AArch64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, jcstress run

Thanks for reviews! All tests are passing (there are some known AArch64 failures). But it is a large patch, so I will integrate this on Monday to avoid dealing with any breakages over the weekend.

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

PR Comment: https://git.openjdk.org/jdk/pull/28538#issuecomment-3588824144

From mbaesken at openjdk.org  Fri Nov 28 15:55:17 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Nov 2025 15:55:17 GMT
Subject: RFR: 8372643: Warning message on macos when building the JDK - (arm64)
 /tmp/lto.o unable to open object file: No such file or directory
Message-ID: 

When building the recent mainline JDK (26), I see the following warning messages:

warning: (arm64) /tmp/lto.o unable to open object file: No such file or directory
warning: no debug symbols in executable (-arch arm64)


The build completes normally even with these warnings.
I am on macos aarch64, but I see the same warning on macos x64 and aarch64 in our CI.
Seems we miss a linker flag for libs built with lto (libsplashscreen), because the Apple linker has the following issue

https://clang.llvm.org/docs/CommandGuide/clang.html
Note

`
On Darwin, when using [-flto](https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-flto) along with [-g](https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-g) and compiling and linking in separate steps, you also need to pass -Wl,-object_path_lto,.o at the linking step to instruct the ld64 linker not to delete the temporary object file generated during Link Time Optimization (this flag is automatically passed to the linker by Clang if compilation and linking are done in a single step). This allows debugging the executable as well as generating the .dSYM bundle using dsymutil(1).`

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

Commit messages:
 - JDK-8372643

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

PR: https://git.openjdk.org/jdk/pull/28559

From duke at openjdk.org  Fri Nov 28 19:40:50 2025
From: duke at openjdk.org (Nick Hall)
Date: Fri, 28 Nov 2025 19:40:50 GMT
Subject: RFR: 8349546: Linux support for Kerberos "nativeccache"
 functionality [v13]
In-Reply-To: 
References: 
 
 <4_rkUaOwuH6_uQRt0HnZKey0t4Z83CQvcrHEqS-VYys=.c825780e-778b-431e-9800-b3a548f1355d@github.com>
 
Message-ID: 

On Wed, 26 Nov 2025 14:08:51 GMT, Erik Joelsson  wrote:

> If you want to drive adoption, or even think about making this mandatory at build time, then at the very least you need to make sure the devkits produced by the makefiles under `make/devkit/...` contain the necessary build time dependencies and generally work with this feature. At least at Oracle we rely on these for our builds and my impression is that at least some other vendors do too.

Thanks.  I had a go at this today, but am struggling to build a devkit (even without any changes).  Can you recommend a suitable host OS for building one, and which OS targets I should use to build the devkits to test?

(I've tried building a devkit for Fedora 41 using both RHEL8 and Fedora 41 as host OSes, but am getting a variety of issues in the build)

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

PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3590211184

From prr at openjdk.org  Sat Nov 29 01:51:47 2025
From: prr at openjdk.org (Phil Race)
Date: Sat, 29 Nov 2025 01:51:47 GMT
Subject: RFR: 8372534: Update Libpng to 1.6.51
In-Reply-To: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
Message-ID: 

On Thu, 27 Nov 2025 01:12:48 GMT, Jayathirth D V  wrote:

> Upgrade libpng used for Splashscreen from 1.6.47 to 1.6.51 version.

I assume all splash screen tests PASS ?

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28518#pullrequestreview-3520303089

From jdv at openjdk.org  Sun Nov 30 15:53:47 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Sun, 30 Nov 2025 15:53:47 GMT
Subject: RFR: 8372534: Update Libpng to 1.6.51
In-Reply-To: 
References: <3LLhVAk4ZEb7Jd1DtXsdSh86IO0v9ESh8Rxy2XbPK0g=.7b1ba348-7cfd-4499-8f1f-77a1056079ea@github.com>
 
Message-ID: <1SGfRUTyMfMhYv9D1VS3sldPARt4uF-Lr2LGYXWzgIo=.c7c15f97-c53c-4636-bc25-b475a08575a2@github.com>

On Sat, 29 Nov 2025 01:48:41 GMT, Phil Race  wrote:

> I assume all splash screen tests PASS ?

Yes, Automated tests are verified in CI and i have verified manual tests locally.

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

PR Comment: https://git.openjdk.org/jdk/pull/28518#issuecomment-3592727853