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: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>

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: <z2m4zM6bsfP7WdLKYPlKJBabL-DVKQEDfTJ_g08yL3Q=.0e757cf1-208d-4363-be1d-3ea544240ba2@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <z2m4zM6bsfP7WdLKYPlKJBabL-DVKQEDfTJ_g08yL3Q=.0e757cf1-208d-4363-be1d-3ea544240ba2@github.com>
Message-ID: <b-SKqx8W6m7LqwUwskj1vY95HRTzxCYBUCKO3j0j6A0=.1103b4db-bf1c-4aaa-a44d-e560b972799f@github.com>

On Wed, 29 Oct 2025 14:35:46 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <H97VJmEKWaQtawOkZsPaxC98RvDtUkic7x2aAf3Di6w=.a0082c59-4b61-4dff-85cb-8795d31f66e1@github.com>
References: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
 <H97VJmEKWaQtawOkZsPaxC98RvDtUkic7x2aAf3Di6w=.a0082c59-4b61-4dff-85cb-8795d31f66e1@github.com>
Message-ID: <EoNfBEfjDYiQSbFrdqmHAyoCAiW1DL-zZBMBRiIaMA0=.a2ab4a61-c43d-4506-8ed7-a3e2a9096fee@github.com>

On Wed, 29 Oct 2025 17:23:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> 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: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
References: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
Message-ID: <rY7ulvPy68GMybvvrrWP8d4oT27FJoNMEK-kjHSb3uQ=.db1e5e8f-2ce5-4ade-bdb3-58b05a9849dc@github.com>

On Sat, 1 Nov 2025 21:08:57 GMT, Mohamed Issa <missa at openjdk.org> 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: <V-BNOBiMS7EhU2yfL0NQNJdGu590cpvEST7UBQ-MFz0=.941bae9c-cefd-43c3-bf82-fadaa82d2b02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <V-BNOBiMS7EhU2yfL0NQNJdGu590cpvEST7UBQ-MFz0=.941bae9c-cefd-43c3-bf82-fadaa82d2b02@github.com>
Message-ID: <5uVrChmuvWYTVm5OgP-PoYFS-Sg3YkEVaUB8q9lIMqE=.8eab6e42-19e3-4a0d-bb62-d16c362ed670@github.com>

On Fri, 31 Oct 2025 22:48:53 GMT, Nick Hall <duke at openjdk.org> 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: <kPI53wkRZsLOQmMjbdTQM41ZLAt38evgMjwprONSQoQ=.aa87e062-d7b5-4686-8e00-13a46d209f9f@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <JrwuOh7LRWEZoxE7t7NxxkLlXf9Ha6E8ycZO-VLrwvk=.79efbf77-3015-4620-a83f-311b592c66bc@github.com>
 <5OAU93NhLcyzzkr2M029oa4nQnyzqqDQqBwvJjNhKsA=.9bca2a2c-4f38-47a5-9a04-8cc415a99008@github.com>
 <8O4Yy-dC8NorVuQ6MNOSmx2neronvvnG1BscwtjjOYI=.47d69f86-71ed-4b41-a328-eb222c332b6e@github.com>
 <rYzlbrvNX9MjncrPmAiCWNaVqIgC_bw6Fnew9iXSMRs=.9e29cf9a-67c7-41dd-8352-148620e3dc88@github.com>
 <kPI53wkRZsLOQmMjbdTQM41ZLAt38evgMjwprONSQoQ=.aa87e062-d7b5-4686-8e00-13a46d209f9f@github.com>
Message-ID: <E4rRQXtgPJV4VUJaxHyg0WwxAki-M6Ff4PnXDp_Tgfc=.34ba43f5-5c4c-4ce8-9cfe-51f6db2da759@github.com>

On Thu, 30 Oct 2025 15:41:06 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
Message-ID: <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>

On Thu, 4 Sep 2025 15:22:57 GMT, Archie Cobbs <acobbs at openjdk.org> 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: <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
Message-ID: <n0S7kzJSUFsFD2Hcjbv2nRCAKgyIv_fu_5kEi0gFiRY=.a14c970d-dfe6-44de-aaf4-b656b4267d55@github.com>

On Mon, 3 Nov 2025 16:47:56 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
Message-ID: <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@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 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: <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
Message-ID: <0D_jgs9w47rAKwt5Udla_7C1bfb7Moc14-Fr4RsTq64=.27341088-069f-4208-817e-7391e1348a54@github.com>

On Mon, 3 Nov 2025 16:44:13 GMT, Jan Lahoda <jlahoda at openjdk.org> 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: <n0S7kzJSUFsFD2Hcjbv2nRCAKgyIv_fu_5kEi0gFiRY=.a14c970d-dfe6-44de-aaf4-b656b4267d55@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
 <n0S7kzJSUFsFD2Hcjbv2nRCAKgyIv_fu_5kEi0gFiRY=.a14c970d-dfe6-44de-aaf4-b656b4267d55@github.com>
Message-ID: <nO1fo0YWP7DtcEliG7OwWB9PGTaq-EBm2lJMytOKgBs=.3abe305d-632a-4e14-a121-c8deebdf4ba9@github.com>

On Mon, 3 Nov 2025 18:09:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> 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: <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@github.com>
Message-ID: <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com>

On Mon, 3 Nov 2025 18:32:57 GMT, Archie Cobbs <acobbs at openjdk.org> 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: <rY7ulvPy68GMybvvrrWP8d4oT27FJoNMEK-kjHSb3uQ=.db1e5e8f-2ce5-4ade-bdb3-58b05a9849dc@github.com>
References: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
 <rY7ulvPy68GMybvvrrWP8d4oT27FJoNMEK-kjHSb3uQ=.db1e5e8f-2ce5-4ade-bdb3-58b05a9849dc@github.com>
Message-ID: <zGI7vqlqzSwXkrhEy5CS0TN3eBjbM24wjExAHT6Wsj0=.51759c9d-5087-4496-b12c-de799facfc3e@github.com>

On Mon, 3 Nov 2025 13:00:31 GMT, Erik Joelsson <erikj at openjdk.org> 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: <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
 <Iy_CfNMy36V4ldrn50W8lFjz_BfLkqbcRTSIncUpKpw=.1727ea09-0b72-4b4f-9605-9a8873216319@github.com>
Message-ID: <8Usem4e_ob2t8vNthfAQ91duUt2eVCToYUttekAau-o=.b9cc0f2b-38b4-410d-a59a-c6b82a5b9679@github.com>

On Thu, 30 Oct 2025 22:55:34 GMT, Erik Joelsson <erikj at openjdk.org> 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: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
References: <ZBbxE-WjCaO17qyMaB51tDnLr8o2RK7pSa98X1u03tA=.83d6e6f7-cfb4-406c-aa53-1a0fac838c02@github.com>
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: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <rPvEyWXtBAqBsnyea0B0iaX_Z7a3OsftT4vxxaKtVlA=.94566266-84ea-40ac-abea-2e6b470a15ff@github.com>
 <05yTbGH4d3Remac9l0EN0P6Li94CmDTyXvalkwb5vhI=.1a640f2e-df85-4add-88a9-e6613cfe3f4c@github.com>
Message-ID: <jSqJ-aHRJ9vxqzkPfdmgTtXwh0EH51WYKg5I6wbh2tE=.da612e30-1305-4a88-9ef1-a1a5b961452b@github.com>

On Mon, 3 Nov 2025 18:30:22 GMT, Hannes Greule <hgreule at openjdk.org> 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: <nO1fo0YWP7DtcEliG7OwWB9PGTaq-EBm2lJMytOKgBs=.3abe305d-632a-4e14-a121-c8deebdf4ba9@github.com>
References: <yOtYq-gzXXB5K_tq-UmcsNCPpgyrT7atOoj_w9lTBg4=.f61deb50-beab-47a1-8827-9bf758229380@github.com>
 <D5PKJUBFYVYJxCXPfdbH7RnSw7rPtSH7Gex_KXLt6KI=.fecab525-3d35-4862-bdbb-862b90e74406@github.com>
 <n0S7kzJSUFsFD2Hcjbv2nRCAKgyIv_fu_5kEi0gFiRY=.a14c970d-dfe6-44de-aaf4-b656b4267d55@github.com>
 <nO1fo0YWP7DtcEliG7OwWB9PGTaq-EBm2lJMytOKgBs=.3abe305d-632a-4e14-a121-c8deebdf4ba9@github.com>
Message-ID: <DkXaykkQSu761CTKefPNueZZmh6ddn7WG8Tqpaz0iz0=.bb0123e6-b552-423f-bda7-98ff3927d476@github.com>

On Mon, 3 Nov 2025 18:31:54 GMT, Archie Cobbs <acobbs at openjdk.org> 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: <rY7ulvPy68GMybvvrrWP8d4oT27FJoNMEK-kjHSb3uQ=.db1e5e8f-2ce5-4ade-bdb3-58b05a9849dc@github.com>
References: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
 <rY7ulvPy68GMybvvrrWP8d4oT27FJoNMEK-kjHSb3uQ=.db1e5e8f-2ce5-4ade-bdb3-58b05a9849dc@github.com>
Message-ID: <ch2LpAJ-qCCHPClijBV-Tc6a6CC7W5s1fYczt7nXeW4=.a4d31213-2a0c-49e8-88ba-9f51e4bf4f61@github.com>

On Mon, 3 Nov 2025 13:00:31 GMT, Erik Joelsson <erikj at openjdk.org> 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: <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
 <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
 <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
Message-ID: <dVfOLhSkfBz7zhE4EEqyX3Q7kAkKJ4Os4D-Enyqqsdg=.a37cc396-4514-4642-9510-7b8be901fddc@github.com>

On Thu, 23 Oct 2025 16:06:11 GMT, Ioi Lam <iklam at openjdk.org> 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: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
References: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
Message-ID: <nKjA4cxq1r2hSq3SHIMmb6h-52Vc7aaWKNX4RxmSPeI=.408d98da-fd7a-4c86-ac54-97d33c1cade9@github.com>

On Sat, 1 Nov 2025 21:08:57 GMT, Mohamed Issa <missa at openjdk.org> 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: <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
Message-ID: <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>

On Thu, 30 Oct 2025 08:43:45 GMT, Erik ?sterlund <eosterlund at openjdk.org> 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: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
 <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
 <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>
 <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com>
Message-ID: <qJ7CNxOwk8FRMau_RQfJ2NhDEzucrvNGJbCiRQS13LE=.1b8ef1b7-9a37-4685-9e1a-5d6eb42adf61@github.com>

On Thu, 30 Oct 2025 15:48:41 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
References: <eM8VGBY-pKKI5aJmH0XLbOgnpvTxQkWioIA-gW_09Zs=.4b5ca136-4403-42a5-be01-40b079aae341@github.com>
Message-ID: <r6CrZ2B3K5TyhtRxCHrGsiSwF30ZkVFP05CjgcHa3sQ=.0d1a8f5e-de30-4a8d-a2ab-e54b7934610a@github.com>

On Sat, 1 Nov 2025 21:08:57 GMT, Mohamed Issa <missa at openjdk.org> 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 <missa at openjdk.org>
Committer: SendaoYan <syan at openjdk.org>
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: <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <S2W2N0yp34oyXrFJiBlVl9IQtNO7I9sp1Ro8Vw0ktRs=.55c0f8fa-c861-4c3b-807b-3ac1f2c117ab@github.com>
 <qV53d2FEjx4-zB4LOkUkkdUWeVLYqjuou4qMF0aoStc=.8f5ca512-f9c0-41e8-b35a-eb9147e51a9f@github.com>
Message-ID: <Mk5bbH-TwIBNoJ05BedvJPgBJNXMZ_9XH9knqJbdMew=.77f2c317-0f4c-4e37-8724-dcb7f6ddfa2d@github.com>

On Tue, 4 Nov 2025 00:05:59 GMT, Ioi Lam <iklam at openjdk.org> 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: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
References: <jM3Gokptf_bucCgPXtlSqGpH8uOYPRRV9EiPGdTFl5I=.cb67404f-f56e-48d0-9f51-6d8a2dd49530@github.com>
Message-ID: <TM84-1r5XEo6kZjniboVj0jsAPzq0vL0vJcF6kX1sP0=.a2de2af9-0a09-4876-adee-51d75db28179@github.com>

On Tue, 28 Oct 2025 08:40:35 GMT, Volkan Yazici <vyazici at openjdk.org> 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 <vyazici at openjdk.org>
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: <qJ7CNxOwk8FRMau_RQfJ2NhDEzucrvNGJbCiRQS13LE=.1b8ef1b7-9a37-4685-9e1a-5d6eb42adf61@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
 <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
 <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>
 <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com>
 <qJ7CNxOwk8FRMau_RQfJ2NhDEzucrvNGJbCiRQS13LE=.1b8ef1b7-9a37-4685-9e1a-5d6eb42adf61@github.com>
Message-ID: <Fj6Kp98uI3G8eGU9AaJ4kRP_UylQpCZCVehcqNzqrIE=.94da23e3-9557-4964-8029-56130b38a726@github.com>

On Tue, 4 Nov 2025 01:07:28 GMT, Sergey Bylokhov <serb at openjdk.org> 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: <Fj6Kp98uI3G8eGU9AaJ4kRP_UylQpCZCVehcqNzqrIE=.94da23e3-9557-4964-8029-56130b38a726@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
 <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
 <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>
 <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com>
 <qJ7CNxOwk8FRMau_RQfJ2NhDEzucrvNGJbCiRQS13LE=.1b8ef1b7-9a37-4685-9e1a-5d6eb42adf61@github.com>
 <Fj6Kp98uI3G8eGU9AaJ4kRP_UylQpCZCVehcqNzqrIE=.94da23e3-9557-4964-8029-56130b38a726@github.com>
Message-ID: <FmI2B4P8rQ1OUVip7xejNSXcMzTJE5xXDAB8s7p86Q0=.32989c1b-7ec6-463f-b716-94159393d086@github.com>

On Tue, 4 Nov 2025 09:20:29 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <FmI2B4P8rQ1OUVip7xejNSXcMzTJE5xXDAB8s7p86Q0=.32989c1b-7ec6-463f-b716-94159393d086@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
 <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
 <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>
 <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com>
 <qJ7CNxOwk8FRMau_RQfJ2NhDEzucrvNGJbCiRQS13LE=.1b8ef1b7-9a37-4685-9e1a-5d6eb42adf61@github.com>
 <Fj6Kp98uI3G8eGU9AaJ4kRP_UylQpCZCVehcqNzqrIE=.94da23e3-9557-4964-8029-56130b38a726@github.com>
 <FmI2B4P8rQ1OUVip7xejNSXcMzTJE5xXDAB
 8s7p86Q0=.32989c1b-7ec6-463f-b716-94159393d086@github.com>
Message-ID: <NHLThYgD_bRAWrXFhfBWfPZeVUUI5RhbB50uwRcrPkM=.d2505e38-6df4-4c0b-aa79-3e2757a023f3@github.com>

On Tue, 4 Nov 2025 09:29:25 GMT, Julian Waters <jwaters at openjdk.org> 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: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>

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: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <NnnWCE48NkQHktGkNdTcFspWTLOZlYbDT6TY5mzHTe4=.04053336-5ed9-47c9-8184-f29816203350@github.com>

On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla <nbenalla at openjdk.org> 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: <NHLThYgD_bRAWrXFhfBWfPZeVUUI5RhbB50uwRcrPkM=.d2505e38-6df4-4c0b-aa79-3e2757a023f3@github.com>
References: <pm_EFrk19aPY_adEY42rJ7-iRxxv-ITLq7Vu5XHUHnE=.62265a80-af52-4901-bb82-29a6e789447a@github.com>
 <kaExPg8brK_27PRntxC-p6a0y271RRlLkgzcibzoNBw=.894aad4e-7f88-468e-b842-8623d7ffd3d5@github.com>
 <v9bn-RRjyQqc57fpm96ydPZNTT8qbhVAGyMRw4yM7GA=.b6f1d3c2-35f9-40c8-816d-ddea259db520@github.com>
 <CcBVtpt0BI209PXxs6qQfbOHJBYFen_mkO3dEp23CKQ=.35787e1f-d333-4b4b-b88c-41c4f23e5105@github.com>
 <394qDJUJ-MHlE8rLknEddfSV3dy5PuHLKPUxtpr658E=.3661ee28-7df7-4854-a4ce-6453563e4c8b@github.com>
 <IrktPhD9qz21JR05cA0yXzYvBc2ASh3nZDuQ0o_9t6g=.8adaa9fd-c70d-4cba-9fa7-8cbb45058249@github.com>
 <kyHiozs9CCeoVzztBUScCDargsgtU_2OtMUMaapKw1w=.019de49a-16bf-4310-a436-3acfd369e7fd@github.com>
 <809Ep8sEq1en07SmuThJa34v0-oYAdPr6Jhwg4DZTGM=.08fe720e-dc5e-4903-9c3c-e3f5770859e3@github.com>
 <qJ7CNxOwk8FRMau_RQfJ2NhDEzucrvNGJbCiRQS13LE=.1b8ef1b7-9a37-4685-9e1a-5d6eb42adf61@github.com>
 <Fj6Kp98uI3G8eGU9AaJ4kRP_UylQpCZCVehcqNzqrIE=.94da23e3-9557-4964-8029-56130b38a726@github.com>
 <FmI2B4P8rQ1OUVip7xejNSXcMzTJE5xXDAB
 8s7p86Q0=.32989c1b-7ec6-463f-b716-94159393d086@github.com>
 <NHLThYgD_bRAWrXFhfBWfPZeVUUI5RhbB50uwRcrPkM=.d2505e38-6df4-4c0b-aa79-3e2757a023f3@github.com>
Message-ID: <rUGIz2KlX5coWohJh14Oh4fIFetfiqI0fMudbEO-jxI=.3d804ad1-c1fc-4f87-be8f-86ce166eb496@github.com>

On Tue, 4 Nov 2025 10:02:39 GMT, Matthias Baesken <mbaesken at openjdk.org> 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: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>

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: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
References: <p0prpS2bq2uq58_2I36U1Qsu_nPKEfHbKm0OAseuZ9E=.ff096520-ce68-477a-99aa-ccdfb4e4a676@github.com>
Message-ID: <DpO57HYb_SOU1NdMp5r6bpNFDt82V7cl58aqLONp__8=.ce4fd54e-0444-428f-9c68-028d631bcb25@github.com>

> 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