From jdv at openjdk.org Mon Dec 1 05:43:58 2025 From: jdv at openjdk.org (Jayathirth D V) Date: Mon, 1 Dec 2025 05:43:58 GMT Subject: Integrated: 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: <-oMBQGb7A6HK_23xlpq31JXIlBhj1JljQ0RQxMrW9zE=.d03849f6-0b64-463c-9c1a-f49e37bcaab9@github.com> 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. This pull request has now been integrated. Changeset: c7a489db Author: Jayathirth D V URL: https://git.openjdk.org/jdk/commit/c7a489db9e4a7d696623fc2155a5504d9d2adb0d Stats: 638 lines in 21 files changed: 297 ins; 207 del; 134 mod 8372534: Update Libpng to 1.6.51 Reviewed-by: serb, azvegint, prr ------------- PR: https://git.openjdk.org/jdk/pull/28518 From aboldtch at openjdk.org Mon Dec 1 06:55:52 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 1 Dec 2025 06:55:52 GMT Subject: RFR: 8371346: ZGC: Flexible heap base selection [v3] 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 pull request now contains 12 commits: - Merge tag 'jdk-26+26' into zgc_flexible_heap_base Added tag jdk-26+26 for changeset 847fbab7 - 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 - ... and 2 more: https://git.openjdk.org/jdk/compare/847fbab7...4603db33 ------------- Changes: https://git.openjdk.org/jdk/pull/28161/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=02 Stats: 2727 lines in 50 files changed: 1886 ins; 631 del; 210 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 shade at openjdk.org Mon Dec 1 08:02:34 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 1 Dec 2025 08:02:34 GMT Subject: RFR: 8372733: GHA: Bump to Ubuntu 24.04 Message-ID: <8isKzxb721iS99ceR9biNurkXHWvlNHspzIH0GLVN1g=.4033f9ef-0358-4ee6-baa1-5d869d2c029d@github.com> GHA have changed `ubuntu-latest` to `ubuntu-24.04` some time this year. Ubuntu also mentions `22.04` would come off standard support in April 2027, following the usual 5-year cycle. So it is a good time to switch to `24.04` for our current runners. We did the switch to `22.04` 2.5 years back, so we are following the similar 2-year-ish cadence here. Additional testing: - [x] GHA ------------- Commit messages: - Also X11 dependencies - Also fontconfig dependency - Fix Changes: https://git.openjdk.org/jdk/pull/28555/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28555&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372733 Stats: 16 lines in 4 files changed: 7 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28555.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28555/head:pull/28555 PR: https://git.openjdk.org/jdk/pull/28555 From shade at openjdk.org Mon Dec 1 08:44:06 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 1 Dec 2025 08:44:06 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: 3481252c Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/3481252ced7c06c44154ceccc56b12cfd9a490c3 Stats: 2349 lines in 5 files changed: 1156 ins; 1193 del; 0 mod 8372188: AArch64: Generate atomic match rules from M4 stencils Reviewed-by: aph, haosun ------------- PR: https://git.openjdk.org/jdk/pull/28538 From shade at openjdk.org Mon Dec 1 08:44:04 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 1 Dec 2025 08:44:04 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 Over the weekend (60+ hours) jcstress run comes clean, apart from errant `MaxVectorSize` asserts unrelated to this patch. So I am integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28538#issuecomment-3595289184 From nbenalla at openjdk.org Mon Dec 1 08:53:37 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 1 Dec 2025 08:53:37 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] 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 17 additional commits since the last revision: - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - Merge branch 'master' into start-of-release-27 - Changes required for hard 80 character line limit - 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 - ... and 7 more: https://git.openjdk.org/jdk/compare/41b7823d...e5214614 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/78895b2b..e5214614 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=05-06 Stats: 11187 lines in 367 files changed: 7430 ins; 1793 del; 1964 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 clanger at openjdk.org Mon Dec 1 09:02:48 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 1 Dec 2025 09:02:48 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public [v4] In-Reply-To: References: Message-ID: <3ZU647xKHADlBXnoJiI3iZAa6zEzlH28yUw2428cGa0=.e2312aa2-48a6-44a0-a5db-f3c209416463@github.com> > This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`. > > The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough to present line numbers in hs-err files. > > During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored. > > With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs. Christoph Langer 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: - Implement new strategy - Merge branch 'master' into JDK-8351842 - Merge branch 'master' into JDK-8351842 - Merge branch 'master' into JDK-8351842 - Fix tests - JDK-8351842 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24012/files - new: https://git.openjdk.org/jdk/pull/24012/files/e8bff098..7a409863 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=02-03 Stats: 333764 lines in 3194 files changed: 217067 ins; 72151 del; 44546 mod Patch: https://git.openjdk.org/jdk/pull/24012.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24012/head:pull/24012 PR: https://git.openjdk.org/jdk/pull/24012 From clanger at openjdk.org Mon Dec 1 09:21:09 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 1 Dec 2025 09:21:09 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public [v5] In-Reply-To: References: Message-ID: > This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`. > > The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough to present line numbers in hs-err files. > > During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored. > > With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs. Christoph Langer has updated the pull request incrementally with one additional commit since the last revision: Revert to build of stripped pdbs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24012/files - new: https://git.openjdk.org/jdk/pull/24012/files/7a409863..96aef215 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=03-04 Stats: 5 lines in 1 file changed: 1 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24012.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24012/head:pull/24012 PR: https://git.openjdk.org/jdk/pull/24012 From clanger at openjdk.org Mon Dec 1 09:31:58 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 1 Dec 2025 09:31:58 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public [v6] In-Reply-To: References: Message-ID: <7xjbY7Wkdo7ImiFeTdjUWgYkB-7155QLLxtZ13M3-Io=.d86b647e-6335-43ea-bf1c-ccd2113e74dd@github.com> > This PR addresses an issue that can be observed when building on Windows with configure options `--enable-linkable-runtime` and `--with-external-symbols-in-bundles=public`. > > The problem is that with this special build configuration, we build two sets of .pdb files for the binaries. The first set is the standard debug symbols files named .pdb. The second set consists of stripped debug symbols file called .stripped.pdb which have less information but enough to present line numbers in hs-err files. > > During build we use the *.stripped.pdb files for compiling the jmods and also the bundle files. However, in the images folder, both sets of .pdb files exist. The tests for runtime linking will now, in the absence of jmod files, pick up the .pdb files (without *stripped*) from images, but in the runtime the hashes of the *stripped* files are stored. > > With this change, the standard .pdb files in the `--with-external-symbols-in-bundles=public` configuration are now the stripped files and we create a set of full pdb files named *.full.pdb. Jmods and Bundles still contain the stripped pdb files and we also fix the issue that the debug symbols bundle also contained stripped pdb files so far. With this fix, it will contain the full pdb files and extracting these over a JDK runtime will replace stripped pdbs with full pdbs. Christoph Langer has updated the pull request incrementally with two additional commits since the last revision: - Cleanup comment - Fix pdb filtering for JMODs build ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24012/files - new: https://git.openjdk.org/jdk/pull/24012/files/96aef215..ca92b6a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24012&range=04-05 Stats: 9 lines in 2 files changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24012.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24012/head:pull/24012 PR: https://git.openjdk.org/jdk/pull/24012 From clanger at openjdk.org Mon Dec 1 10:42:56 2025 From: clanger at openjdk.org (Christoph Langer) Date: Mon, 1 Dec 2025 10:42:56 GMT Subject: RFR: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public [v3] In-Reply-To: References:

Message-ID: On Wed, 22 Oct 2025 22:47:34 GMT, Erik Joelsson wrote: >> OK, I believe I understand what you're saying. Do you know where the place is where the JDK_IMAGE_DIR is created and renaming/filtering of the pdb files would need to happen? > >> OK, I believe I understand what you're saying. Do you know where the place is where the JDK_IMAGE_DIR is created and renaming/filtering of the pdb files would need to happen? > > So the change would be to _not_ copy debug symbols to the `JDK_IMAGE_DIR` when `--with-external-symbols-in-bundles=public` is set. I think this would be the line you need to put conditions around: https://github.com/openjdk/jdk/blob/be18e7ecfd2e89a0abb168e0d9a5b69598e2199f/make/Images.gmk#L307 OK, finally I have updated my PR to implement the suggestions of @erikj79. Now the exploded image during the build will only contain the full pdb files and in the actual JDK and JRE images, we'll have the stripped pdb files (as well as in the jmods), if the option is set. And this also propagates to bundles. The debug image/debug bundle will of course only have the full symbol files. I also update the test test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java to expect debug symbols in case configure option `--with-external-symbols-in-bundles` is non-empty. This also contains some updates to the Whitebox functionality for checking which kind of debug symbols should be delivered and cleanup of test test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java which was modified already with [JDK-8370064](https://bugs.openjdk.org/browse/JDK-8370064). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24012#issuecomment-3595830306 From jpai at openjdk.org Mon Dec 1 12:44:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 12:44:57 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 In-Reply-To: References: Message-ID: On Fri, 28 Nov 2025 15:47:04 GMT, Matthias Baesken wrote: > 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).` Hello Matthias @MBaesken, I'll run this PR in our CI and see how it goes. I'll update here once I have the results. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28559#issuecomment-3596363051 From erikj at openjdk.org Mon Dec 1 14:40:19 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 Dec 2025 14:40:19 GMT Subject: RFR: 8372393: Document requirement for separate metallib installation with Xcode 26.1.1 [v2] In-Reply-To: References:

Message-ID: On Thu, 27 Nov 2025 11:04:29 GMT, Galder Zamarre?o wrote: >> 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 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28489#pullrequestreview-3525324245 From erik.joelsson at oracle.com Mon Dec 1 14:45:18 2025 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 1 Dec 2025 06:45:18 -0800 Subject: Mac devkit requires changes for XCode 26 In-Reply-To: References: Message-ID: <505682a1-1308-4e1c-8c37-da01da04a321@oracle.com> Hello Galder, At Oracle we use this script to generate new devkits every time we update the toolchains we use for official builds, so it should be up to date and working for the latest toolchain we use at least, which at this time is Xcode 15.4. We have not yet jumped to Xcode 26, but when we do, we will make the script work unless someone else beats us to it. The expectation when running the script should not be to first have to copy things around in the installation directory of Xcode. The script should handle this automatically. However, it could be that we need to supply a path to both Xcode and metal going forward. I have not looked into this at all yet. /Erik On 11/27/25 04:20, Galder Zamarreno wrote: > 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 erikj at openjdk.org Mon Dec 1 14:57:09 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 Dec 2025 14:57:09 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 Fri, 28 Nov 2025 19:38:20 GMT, Nick Hall wrote: > 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) I haven't used this myself in a while, but I believe our internal kits use Oracle Linux 7 as host (in a container) and Oracle Linux 6 as target. RHEL should be equivalent to Oracle Linux, at least in this context. These are quite old, but the motivation for us to use devkits is to guarantee compatibility with old Linux versions. The host OS dictates the oldest where the kit itself can be used and the target dictates the oldest where the subsequently built JDK can be used. That said, getting a devkit to compile can be finicky for all sorts of reasons. The important part in this case is the sysroot, which is what you are going to change here, by adding extra packages. At least in theory, you could generate just a sysroot and supply that to the JDK build to verify this. I don't think there is a readily available make target for that though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28075#issuecomment-3596996889 From erikj at openjdk.org Mon Dec 1 15:01:23 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 Dec 2025 15:01:23 GMT Subject: RFR: 8372733: GHA: Bump to Ubuntu 24.04 In-Reply-To: <8isKzxb721iS99ceR9biNurkXHWvlNHspzIH0GLVN1g=.4033f9ef-0358-4ee6-baa1-5d869d2c029d@github.com> References: <8isKzxb721iS99ceR9biNurkXHWvlNHspzIH0GLVN1g=.4033f9ef-0358-4ee6-baa1-5d869d2c029d@github.com> Message-ID: On Fri, 28 Nov 2025 11:56:26 GMT, Aleksey Shipilev wrote: > GHA have changed `ubuntu-latest` to `ubuntu-24.04` some time this year. Ubuntu also mentions `22.04` would come off standard support in April 2027, following the usual 5-year cycle. So it is a good time to switch to `24.04` for our current runners. > > We did the switch to `22.04` 2.5 years back, so we are following the similar 2-year-ish cadence here. > > Additional testing: > - [x] GHA Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28555#pullrequestreview-3525446158 From liach at openjdk.org Mon Dec 1 16:03:38 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 16:03:38 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: