From kbarrett at openjdk.org  Sat Nov  1 00:16:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 1 Nov 2025 00:16:02 GMT
Subject: RFR: 8365940: Misleading macro in jvm_md.h:57
In-Reply-To: <rZYnv8CGw7v1jTBwZG8Us5zNYuvd_30C3GzG4gWait4=.56e36e84-de54-4a5c-9819-8314275a565a@github.com>
References: <rZYnv8CGw7v1jTBwZG8Us5zNYuvd_30C3GzG4gWait4=.56e36e84-de54-4a5c-9819-8314275a565a@github.com>
Message-ID: <Vdvt1HZag3V-4N4Kj9rd3rasxN7BecIFIA4oZSussNQ=.09880864-8fe9-45f8-97d0-04b3db17237c@github.com>

On Wed, 29 Oct 2025 19:27:29 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The macro `JVM_MAXPATHLEN` should expand to the result of `MAXPATHLEN + 1` as the original result may lead to a different value when using the macro as part of an expression. Verified with tier 1-5 tests.

I'm approving this change, since it's clearly correct. Treat my earlier
comment as a suggestion for further work. I've even filed an issue for it:
https://bugs.openjdk.org/browse/JDK-8371082

Marked as reviewed by kbarrett (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28049#pullrequestreview-3406658462
PR Review: https://git.openjdk.org/jdk/pull/28049#pullrequestreview-3406658733

From henryjen at openjdk.org  Sat Nov  1 15:49:38 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Sat, 1 Nov 2025 15:49:38 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
Message-ID: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>

JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.

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

Commit messages:
 - 8369838: Likely invalid assert or function call in jimage.cpp

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

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

From alanb at openjdk.org  Sun Nov  2 09:04:00 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 2 Nov 2025 09:04:00 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
In-Reply-To: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
Message-ID: <XNBbyJfAx2wnQlxLafF0AzMP7qJtJPm09HHHbY7SxWg=.70b7cf87-f156-4056-827e-e7867b5be48c@github.com>

On Sat, 1 Nov 2025 15:42:37 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.

Would it be possible to update the PR with a brief summary on what testing has been done, or just confirm that at least tier1-5 has been run.  It would indeed be a bug if JImageFindResource were called with a zero-length module name so just want to make sure the assert doesn't trigger in some unusual configuration.

As regards asserts vs. JIMAGE_* functions returning errors then I assume errors would be preferable. The classes in classLoader.cpp is the only user so it wouldn't be hard to audit the usage to make sure that they check for errors.

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

PR Comment: https://git.openjdk.org/jdk/pull/28098#issuecomment-3477557140

From mbaesken at openjdk.org  Mon Nov  3 07:40:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 3 Nov 2025 07:40:01 GMT
Subject: RFR: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly
In-Reply-To: <IItpvN8JEodrEUeZmwq8cUZ8Sgph8lMMmmvaUxx85tw=.d7b0edf2-ee65-4430-b9ff-9a4a6904cb61@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
 <p5BjIjrbL0xNfHYuide9R7K8dr9-IGyZrwWM5K5PzAI=.5650f8b1-0a4e-497b-8dcc-059f9f30e7f5@github.com>
 <pMu6w8nEQsIPOfjLqvqFIaRHYkboLBgVou0Ex8QgMbI=.5d16575e-6a1b-476e-a4bc-8d75e11d1752@github.com>
 <bx7pyQJDDz6JxE-QAgNWJzyj8LGYN885Sbxs1nweYZQ=.1dac9648-a49c-45b8-97d7-cbbb167abcbb@github.com>
 <5Ijk8bQ8nehFkJdrjRH0-nmv7QB5OZKZCLD--AEpFZo=.cb96b397-62cc-4c27-95b4-421385a8ae9b@github.com>
 <IItpvN8JEodrEUeZmwq8cUZ8Sgph8lMMmmvaUxx85tw=.d7b0edf2-ee65-4430-b9ff-9a4a6904cb61@github.com>
Message-ID: <_898zW9XhM7AJlrmu9uHXnfT213fSFe-qSVOAp-jwtQ=.901fd230-dde6-4743-806b-1098104ae6d9@github.com>

On Fri, 31 Oct 2025 18:46:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> I'm just spitballing here based on my experience listening to @xmas92 talk about ASAN in ZGC. Could it be that ASAN is reserving memory at the lower end of the virtual address space, making it difficult to get zero-based Compressed Oops. In that case, we need som extra memory to "efficiently implement null checks.", which turns out to be 2M in this case, which looks like an extra large page.
>> https://github.com/openjdk/jdk/blob/8236800deb5b99a027b0944f6c512c0f31d030df/src/hotspot/share/memory/memoryReserver.cpp#L612-L614
>
> Thanks for sharing your info. It describes the 2M diff in reserved amount.

So I think changing/relaxing the check

`output_detail.shouldContain("Java Heap (reserved=65536KB, committed=65536KB)");`

in case of asan-enabled binaries would make sense, we do not need to disable the whole test when running with asan.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28055#discussion_r2485556995

From azafari at openjdk.org  Mon Nov  3 09:31:27 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Nov 2025 09:31:27 GMT
Subject: RFR: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp [v6]
In-Reply-To: <XUXKp35oMd4GhcVbM4bxvqLlf6zkM1yAmAnJOkiYeMQ=.db71fe7a-d05c-4e42-ae59-675662e8aae7@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
 <FJmjSIo5ObjK-444QVFKghcBWDzeunvEmS5-WeTv6U4=.21b95e49-6e6c-4610-a5e9-85dc79758bab@github.com>
 <XUXKp35oMd4GhcVbM4bxvqLlf6zkM1yAmAnJOkiYeMQ=.db71fe7a-d05c-4e42-ae59-675662e8aae7@github.com>
Message-ID: <w8_eNISy6Y6eEgVA1MpwD-DxqX5tsJtSVzIYDn9bD5k=.d5ec309d-3378-4428-a053-1fad02e4aec9@github.com>

On Mon, 20 Oct 2025 17:08:18 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix after wrong merge.
>
>> Dear @iklam , in #26955, it is suggested to use `uintptr_t` for addresses in pointer arithmetics and cast them to `address` when we pass them into functions. There are some of this conversions in related code here, do you want me to do this or as a separate RFE?
> 
> I think we should probably do that in a separate RFE. The CDS code has a mixed use of intptr_t, address and char* for addresses. We should probably change all of them to a single type, and I agree that  intptr_t is the best of the three.

Thank you @iklam and @dholmes-ora for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/26983#issuecomment-3479613974

From azafari at openjdk.org  Mon Nov  3 09:31:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Nov 2025 09:31:28 GMT
Subject: Integrated: 8366062: [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp
In-Reply-To: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
References: <ThshPn4opNV4ChF_608Q4tqu9XvRlPSR7poud_untM4=.cfac66ce-af53-476c-a5bf-fe1833f49166@github.com>
Message-ID: <G7sdAIlawmvcQ0KgRjXM18bZMQ4-J8dWKnivnxWIv8w=.e977796e-e11a-407f-9dd0-27959180bbf4@github.com>

On Thu, 28 Aug 2025 10:15:47 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> It is acceptable that the `SharedBaseAddress` option gets `0` at command line. The corresponding pointer arithmetic with `0` (`nullptr`) in archiveBuilder is UB.
> Specific casts are used to avoid UBSAN error.
> 
> Tests:
> linux-x64-debug: tier1 passed

This pull request has now been integrated.

Changeset: 4e63c041
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e63c0412e3a05af1ff783d0587e03a6817b8e0d
Stats:     11 lines in 1 file changed: 5 ins; 1 del; 5 mod

8366062: [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp

Reviewed-by: iklam, dholmes

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

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

From mbaesken at openjdk.org  Mon Nov  3 10:34:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 3 Nov 2025 10:34:07 GMT
Subject: RFR: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly [v2]
In-Reply-To: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
Message-ID: <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>

> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error :
> `
> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr`
> 
> instead we see in the log e.g. :
> `Java Heap (reserved=67584KB, committed=65536KB)`
> 
> so it looks like adding asan to the build changes those memory values a bit.
> We should disable this test when using asan enabled binaries .

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

  Disable only little test part in case of asan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28055/files
  - new: https://git.openjdk.org/jdk/pull/28055/files/9ef0c913..639fcf1e

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

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

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

From duke at openjdk.org  Mon Nov  3 12:05:10 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 3 Nov 2025 12:05:10 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
In-Reply-To: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
Message-ID: <Wp-r4VnuqUsPPJdppMh3B8TAoJNjflUIdMkc7lJJg3Q=.1a476811-af03-454b-bc12-3e9ca0745d1d@github.com>

On Sat, 1 Nov 2025 15:42:37 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.

Assuming there are no other calls to this API passing "", this is what I imagined should be done.

src/hotspot/share/classfile/classLoader.cpp line 415:

> 413: ClassFileStream* ClassPathImageEntry::open_stream_for_loader(JavaThread* current, const char* name, ClassLoaderData* loader_data) {
> 414:   jlong size;
> 415:   JImageLocationRef location;

Maybe set to null explicitly here to indicate we know there are code paths which leave the initial value untouched.

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

PR Review: https://git.openjdk.org/jdk/pull/28098#pullrequestreview-3410683774
PR Review Comment: https://git.openjdk.org/jdk/pull/28098#discussion_r2486231932

From azafari at openjdk.org  Mon Nov  3 12:24:19 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Nov 2025 12:24:19 GMT
Subject: RFR: 8371142: [BACKOUT] [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp
Message-ID: <t_1ZQx8ufMrFXOF0Iw3WhcNHnBPtY1xvkie1Lkjv1ts=.bf889fc0-4c9b-445d-814b-f76114561a05@github.com>

The changes in [8366062](https://bugs.openjdk.org/browse/JDK-8366062) are reverted.
The error resulted by the original change (8366062) to be investigated.
Failed test is re-run locally and passed.

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

Commit messages:
 - 8371142: [BACKOUT] [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp

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

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

From coleenp at openjdk.org  Mon Nov  3 12:39:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Nov 2025 12:39:56 GMT
Subject: RFR: 8364360: Defining hidden class with no room in constant pool
 crashes the VM [v7]
In-Reply-To: <feFYbsRiU5tWV4IKhBBPM4DUxtrQT6_-0RTd8ggbDw0=.f2c77e9a-6ad5-41d2-8cc8-0a67047d2fab@github.com>
References: <cp_3147bEZkSEOpThdhIEdavaHEWrilRoZ4HrPeWrdI=.36979a34-9889-407f-84dd-ed35596c052a@github.com>
 <feFYbsRiU5tWV4IKhBBPM4DUxtrQT6_-0RTd8ggbDw0=.f2c77e9a-6ad5-41d2-8cc8-0a67047d2fab@github.com>
Message-ID: <zu_5RgzgtHQ3rgT19QvQSNUoLHJM_q7N5qwwNaIuNkc=.002a3f18-e488-4b3f-96cf-d0591f6ab6d2@github.com>

On Fri, 31 Oct 2025 19:24:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Check for constant pool index overflow and throw ClassFormatError instead of crashing.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add an explicit overflow test.

Thanks for reviewing David, Matias and Chen.

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

PR Comment: https://git.openjdk.org/jdk/pull/27964#issuecomment-3480310834

From coleenp at openjdk.org  Mon Nov  3 12:39:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Nov 2025 12:39:57 GMT
Subject: RFR: 8364360: Defining hidden class with no room in constant pool
 crashes the VM [v6]
In-Reply-To: <Xn_RlMr_hDF4rAuNtV0GfywNDJXZ9ulLJTQaJEf1MqE=.b5ed745c-8532-4a62-a14d-ddd08e37153d@github.com>
References: <cp_3147bEZkSEOpThdhIEdavaHEWrilRoZ4HrPeWrdI=.36979a34-9889-407f-84dd-ed35596c052a@github.com>
 <D8MXUDFxNxR-J_tq5FFxv59dntQ-eAgXKmAH3d-g8F4=.8c0c0569-0849-425c-a916-dc169ba1ea4a@github.com>
 <QberKM0mXmgZBAMUUBNPahaJcjdJSHlY8ugziqNdQbk=.13335340-41b0-4636-b796-f855a0fbe988@github.com>
 <kcaIKDnpWVJfGwtKLkiD24MUNkmPquuUIlSDv4QvMvg=.3730e820-96ee-4294-b2c2-75dadbb5e49c@github.com>
 <IMSrlt4jCBHqeO7wdps-v_d49pXnsRSJehd99BWX8z0=.48681007-5b43-4af0-b0da-8675737335d9@github.com>
 <Xn_RlMr_hDF4rAuNtV0GfywNDJXZ9ulLJTQaJEf1MqE=.b5ed745c-8532-4a62-a14d-ddd08e37153d@github.com>
Message-ID: <H9fvKOKw8-lG90_tXGLVzK7TrwcAlfKySaKADpMzlLI=.77be0807-e5f1-4fc7-9387-8adda1d264af@github.com>

On Fri, 31 Oct 2025 20:24:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I made this change and reran the VM jck tests.
>
>> Isn't this technically UB behavior? It isn't guaranteed that a u2 will overflow to a low value. It might be safer have cp_size be an int and then guarantee that cp_size < 65535.
> 
> [drive-by comment] Unsigned integer arithmetic is modular arithmetic. Overflow is not UB, it's wrap-around.

Thanks for the drive by info.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27964#discussion_r2486342466

From coleenp at openjdk.org  Mon Nov  3 12:40:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Nov 2025 12:40:00 GMT
Subject: Integrated: 8364360: Defining hidden class with no room in constant
 pool crashes the VM
In-Reply-To: <cp_3147bEZkSEOpThdhIEdavaHEWrilRoZ4HrPeWrdI=.36979a34-9889-407f-84dd-ed35596c052a@github.com>
References: <cp_3147bEZkSEOpThdhIEdavaHEWrilRoZ4HrPeWrdI=.36979a34-9889-407f-84dd-ed35596c052a@github.com>
Message-ID: <2K-VcojDuOmS1N8E4LGcs2wfoAsra6H2Kemdp8JavPU=.bca3eb5f-7577-49ea-822b-5855347e56cf@github.com>

On Thu, 23 Oct 2025 23:54:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Check for constant pool index overflow and throw ClassFormatError instead of crashing.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 6f452ac4
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6f452ac46f17b89f8a9f661ffc8fadc663ae124e
Stats:     64 lines in 2 files changed: 64 ins; 0 del; 0 mod

8364360: Defining hidden class with no room in constant pool crashes the VM

Reviewed-by: matsaave, liach, dholmes

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

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

From coleenp at openjdk.org  Mon Nov  3 13:00:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Nov 2025 13:00:22 GMT
Subject: RFR: 8371142: [BACKOUT] [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp
In-Reply-To: <t_1ZQx8ufMrFXOF0Iw3WhcNHnBPtY1xvkie1Lkjv1ts=.bf889fc0-4c9b-445d-814b-f76114561a05@github.com>
References: <t_1ZQx8ufMrFXOF0Iw3WhcNHnBPtY1xvkie1Lkjv1ts=.bf889fc0-4c9b-445d-814b-f76114561a05@github.com>
Message-ID: <1uwUbEb9XUINoC8mfG8E05s-UYEucVCUvbhfLOMXQFw=.73a20a9c-08a6-471f-a484-af3f079bcc1d@github.com>

On Mon, 3 Nov 2025 12:17:20 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The changes in [8366062](https://bugs.openjdk.org/browse/JDK-8366062) are reverted.
> The error resulted by the original change (8366062) to be investigated.
> Failed test is re-run locally and passed.

Looks like a clean backout.  Please push.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28109#pullrequestreview-3410915694

From azafari at openjdk.org  Mon Nov  3 13:00:23 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Nov 2025 13:00:23 GMT
Subject: RFR: 8371142: [BACKOUT] [ubsan] add non-zero offset to nullptr in
 cds/archiveBuilder.cpp
In-Reply-To: <1uwUbEb9XUINoC8mfG8E05s-UYEucVCUvbhfLOMXQFw=.73a20a9c-08a6-471f-a484-af3f079bcc1d@github.com>
References: <t_1ZQx8ufMrFXOF0Iw3WhcNHnBPtY1xvkie1Lkjv1ts=.bf889fc0-4c9b-445d-814b-f76114561a05@github.com>
 <1uwUbEb9XUINoC8mfG8E05s-UYEucVCUvbhfLOMXQFw=.73a20a9c-08a6-471f-a484-af3f079bcc1d@github.com>
Message-ID: <C0f020j14aS9puAkjYCCYmA6DbyUSPqT1pN5IqMK_b4=.f7ff5746-023e-41f6-9b11-b471787fa745@github.com>

On Mon, 3 Nov 2025 12:55:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The changes in [8366062](https://bugs.openjdk.org/browse/JDK-8366062) are reverted.
>> The error resulted by the original change (8366062) to be investigated.
>> Failed test is re-run locally and passed.
>
> Looks like a clean backout.  Please push.

Thank you for review @coleenp.

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

PR Comment: https://git.openjdk.org/jdk/pull/28109#issuecomment-3480393715

From azafari at openjdk.org  Mon Nov  3 13:00:23 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 3 Nov 2025 13:00:23 GMT
Subject: Integrated: 8371142: [BACKOUT] [ubsan] add non-zero offset to nullptr
 in cds/archiveBuilder.cpp
In-Reply-To: <t_1ZQx8ufMrFXOF0Iw3WhcNHnBPtY1xvkie1Lkjv1ts=.bf889fc0-4c9b-445d-814b-f76114561a05@github.com>
References: <t_1ZQx8ufMrFXOF0Iw3WhcNHnBPtY1xvkie1Lkjv1ts=.bf889fc0-4c9b-445d-814b-f76114561a05@github.com>
Message-ID: <nIWTSEwvypRMTfJcy5F4D5GHcOG0reztYxzPjSEagCI=.0e5226ed-2fd1-48c5-8f3a-e4a07b941b81@github.com>

On Mon, 3 Nov 2025 12:17:20 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The changes in [8366062](https://bugs.openjdk.org/browse/JDK-8366062) are reverted.
> The error resulted by the original change (8366062) to be investigated.
> Failed test is re-run locally and passed.

This pull request has now been integrated.

Changeset: ef464d69
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef464d69399e50aee126a4756fe9a9a19e44d3c4
Stats:     11 lines in 1 file changed: 1 ins; 5 del; 5 mod

8371142: [BACKOUT] [ubsan] add non-zero offset to nullptr in cds/archiveBuilder.cpp

Reviewed-by: coleenp

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

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

From henryjen at openjdk.org  Mon Nov  3 16:14:44 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 3 Nov 2025 16:14:44 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
In-Reply-To: <XNBbyJfAx2wnQlxLafF0AzMP7qJtJPm09HHHbY7SxWg=.70b7cf87-f156-4056-827e-e7867b5be48c@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
 <XNBbyJfAx2wnQlxLafF0AzMP7qJtJPm09HHHbY7SxWg=.70b7cf87-f156-4056-827e-e7867b5be48c@github.com>
Message-ID: <1iMqOErZxkpN5OzOCoUnGpxZ8p82ajtk-lZJMT6tZlQ=.3f7d31a0-a3d6-4a9a-9baa-953b4461f90d@github.com>

On Sun, 2 Nov 2025 09:01:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to update the PR with a brief summary on what testing has been done, or just confirm that at least tier1-5 has been run. It would indeed be a bug if JImageFindResource were called with a zero-length module name so just want to make sure the assert doesn't trigger in some unusual configuration.
> 
> As regards asserts vs. JIMAGE_* functions returning errors then I assume errors would be preferable. The classes in classLoader.cpp is the only user so it wouldn't be hard to audit the usage to make sure that they check for errors.

I have run tier1 and tier2, I'll run others.

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

PR Comment: https://git.openjdk.org/jdk/pull/28098#issuecomment-3481339052

From matsaave at openjdk.org  Mon Nov  3 16:35:04 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 3 Nov 2025 16:35:04 GMT
Subject: RFR: 8365940: Misleading macro in jvm_md.h:57
In-Reply-To: <PZ4p1LD4NTNnAOa4iJ2piZ2nM_A6jaFbomLtHcp5G3w=.899bd572-0717-44a6-9ddb-9fc9e8769c41@github.com>
References: <rZYnv8CGw7v1jTBwZG8Us5zNYuvd_30C3GzG4gWait4=.56e36e84-de54-4a5c-9819-8314275a565a@github.com>
 <PZ4p1LD4NTNnAOa4iJ2piZ2nM_A6jaFbomLtHcp5G3w=.899bd572-0717-44a6-9ddb-9fc9e8769c41@github.com>
Message-ID: <FcFT8KgRUj3l-ZVSaJpxs7tNXvfS7EqMOATRiDIfrC8=.4c2e93e1-a7f8-4697-b7f4-6a688ac7b21b@github.com>

On Thu, 30 Oct 2025 06:08:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The macro `JVM_MAXPATHLEN` should expand to the result of `MAXPATHLEN + 1` as the original result may lead to a different value when using the macro as part of an expression. Verified with tier 1-5 tests.
>
> Trivially fine. Thanks

Thanks for the reviews @dholmes-ora and @kimbarrett!

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

PR Comment: https://git.openjdk.org/jdk/pull/28049#issuecomment-3481435327

From matsaave at openjdk.org  Mon Nov  3 16:37:24 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Mon, 3 Nov 2025 16:37:24 GMT
Subject: Integrated: 8365940: Misleading macro in jvm_md.h:57
In-Reply-To: <rZYnv8CGw7v1jTBwZG8Us5zNYuvd_30C3GzG4gWait4=.56e36e84-de54-4a5c-9819-8314275a565a@github.com>
References: <rZYnv8CGw7v1jTBwZG8Us5zNYuvd_30C3GzG4gWait4=.56e36e84-de54-4a5c-9819-8314275a565a@github.com>
Message-ID: <ZrREjS30r9lkT7-b_JetHj2amm6jXdgbQLqlPbMIQFI=.fe9e3e22-e1e7-4e74-840d-ac4d19626ffc@github.com>

On Wed, 29 Oct 2025 19:27:29 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> The macro `JVM_MAXPATHLEN` should expand to the result of `MAXPATHLEN + 1` as the original result may lead to a different value when using the macro as part of an expression. Verified with tier 1-5 tests.

This pull request has now been integrated.

Changeset: 1922c4fd
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1922c4fd6f10e6eac121462d509d6990ae4f9acd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8365940: Misleading macro in jvm_md.h:57

Reviewed-by: dholmes, kbarrett

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

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

From duke at openjdk.org  Mon Nov  3 21:17:41 2025
From: duke at openjdk.org (David Beaumont)
Date: Mon, 3 Nov 2025 21:17:41 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
In-Reply-To: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
Message-ID: <gX4T5yZFvXj7JURHOB5-QK93qpRIR8sNiaTHtKI9Ess=.69654976-bb1d-4bf1-9c32-d090d226f6f0@github.com>

On Sat, 1 Nov 2025 15:42:37 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.

jimage *can* return non module resources by the other API, which just takes the full jimage location path/name.
The module+name API is really just a slightly more efficient convenience for the case where the caller has both separately.

For reference, I'm writing a lot of changes around jimage stuff right now, and I don't think I've seen any case where an error code would be of any benefit, as opposed to just returning zero.

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

PR Comment: https://git.openjdk.org/jdk/pull/28098#issuecomment-3482634795

From asmehra at openjdk.org  Tue Nov  4 02:18:41 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 4 Nov 2025 02:18:41 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
Message-ID: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>

Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.

Testing:
Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64

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

Commit messages:
 - 8371178: Preserve fast version of getfield and putfield in AOTCache

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

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

From syan at openjdk.org  Tue Nov  4 02:44:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Nov 2025 02:44:04 GMT
Subject: RFR: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly [v2]
In-Reply-To: <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
 <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
Message-ID: <ZAfiwoDztOpOYfPxwvncrk8UsE-Mj3mThwKYkAqYxH0=.4f972326-2798-4fc9-b0c0-81b22a9b1c55@github.com>

On Mon, 3 Nov 2025 10:34:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error :
>> `
>> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr`
>> 
>> instead we see in the log e.g. :
>> `Java Heap (reserved=67584KB, committed=65536KB)`
>> 
>> so it looks like adding asan to the build changes those memory values a bit.
>> We should disable this test when using asan enabled binaries .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable only little test part in case of asan

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28055#pullrequestreview-3413744593

From syan at openjdk.org  Tue Nov  4 02:45:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 4 Nov 2025 02:45:02 GMT
Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365
In-Reply-To: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
References: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
Message-ID: <Kwh3rgdNJmx-Df3UFHgwo1DtMvrGdClKB2X20dwT3cw=.24ab38cc-a943-4039-ba5b-4f1eabaf2bd5@github.com>

On Thu, 30 Oct 2025 10:48:11 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Added a missed header file and fixed copyright year.
> Tested on macosx-aarch64 ASAN build.

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28058#pullrequestreview-3413748235

From asmehra at openjdk.org  Tue Nov  4 03:58:00 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 4 Nov 2025 03:58:00 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
In-Reply-To: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
Message-ID: <oG4H9g4Mxbnx5WV1CaDgJWnk9UzYLgX2uEmUkubJIfk=.f3a4d780-4ec9-4165-8e24-17fac2e36a8f@github.com>

On Tue, 4 Nov 2025 02:10:13 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
> 
> Testing:
> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64

For the record, I tried to preserve `_fast_Xaccess_0` bytecodes (these are the fast versions for the pair `(aload_0, getfield)`) but then these bytecodes breaks `serviceability/jvmti/FieldAccessWatch/FieldAccessWatch.java` test because the JVMTI event notifications for field access are skipped. Morevoer, I believe setting JVMTI breakpoint on the original location of the  `getfield` bytecode won't work either.
 While the notifications to field access can be fixed, enabling breakpoint is more challenging and probably not worth the effort.
So in this patch I only preserve the fast versions of `getfield` and `putfield` bytecodes.

@iklam @adinn can you please review this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/28121#issuecomment-3483654527
PR Comment: https://git.openjdk.org/jdk/pull/28121#issuecomment-3483654973

From ysuenaga at openjdk.org  Tue Nov  4 07:41:13 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 4 Nov 2025 07:41:13 GMT
Subject: RFR: 8371093: Assert "section header string table should be loaded"
 failed on debug VM
Message-ID: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>

When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))


Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C [linux-vdso.so.1+0xe69]
[error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]

Retrying call stack printing without source information...

[error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]


When I checked back trace on GDB, it failed at `assert`.

#12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
    line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
    detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
#13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
#14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407



(gdb) f 13
#13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
    at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
536 assert(false, "section header string table should be loaded");


vDSO is not a regular ELF, so it should be skipped here.

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

Commit messages:
 - 8371093: Assert "section header string table should be loaded" failed on debug VM

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

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

From mbaesken at openjdk.org  Tue Nov  4 08:09:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Nov 2025 08:09:38 GMT
Subject: RFR: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly [v2]
In-Reply-To: <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
 <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
Message-ID: <xjBdpXnGQjeV5LNoDVSxLLQhTp837x5s0EI6rL83dzA=.0fd82217-f1a3-4d03-b185-45975325861f@github.com>

On Mon, 3 Nov 2025 10:34:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error :
>> `
>> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr`
>> 
>> instead we see in the log e.g. :
>> `Java Heap (reserved=67584KB, committed=65536KB)`
>> 
>> so it looks like adding asan to the build changes those memory values a bit.
>> We should disable this test when using asan enabled binaries .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable only little test part in case of asan

Thanks for the review !
May I get a second review ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28055#issuecomment-3484433645

From phubner at openjdk.org  Tue Nov  4 08:34:27 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 08:34:27 GMT
Subject: RFR: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly [v2]
In-Reply-To: <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
 <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
Message-ID: <p7gC8hSiFP-LjbHxIkAJSk2_rGFenI6CW9wCHEHxGmo=.1bd3bd96-b04f-4165-87d3-79f6c0cb6286@github.com>

On Mon, 3 Nov 2025 10:34:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error :
>> `
>> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr`
>> 
>> instead we see in the log e.g. :
>> `Java Heap (reserved=67584KB, committed=65536KB)`
>> 
>> so it looks like adding asan to the build changes those memory values a bit.
>> We should disable this test when using asan enabled binaries .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable only little test part in case of asan

Looks good, thanks for incorporating the whitebox.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/28055#pullrequestreview-3414725573

From iklam at openjdk.org  Tue Nov  4 09:01:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 09:01:36 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it didn't work because by default regular expressions do not match across newlines.
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to use `Pattern.MULTILINE`.
> 
> I tried rerunning the test on macos 26 but couldn't reproduce the condition in the bug report. However, I added sanity test in this version (https://github.com/openjdk/jdk/commit/e690e97262575d083017635fa837ab267686bfe9) and the new regexp seems to catch the output and correctly come to this part of the test case:
> 
> 
> if (forceBase >= end) {
>     throw new SkippedException("Failed to force ccs to any of the given bases. Skipping test.");
> }

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Refactored the various "match" methods in OutputAnalyzer; added tests; reverted changes in AccessZeroNKlassHitsProtectionZone.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28077/files
  - new: https://git.openjdk.org/jdk/pull/28077/files/184bb30c..3b493855

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

  Stats: 94 lines in 3 files changed: 72 ins; 13 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28077.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28077/head:pull/28077

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

From mbaesken at openjdk.org  Tue Nov  4 09:06:10 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Nov 2025 09:06:10 GMT
Subject: RFR: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly [v2]
In-Reply-To: <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
 <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
Message-ID: <-Yl3vfUoSbsUERIYQsRj5piLrk_0iGKDSuvJqDTYFdQ=.56dd9c85-8fa7-4022-bc88-9397c8f58bce@github.com>

On Mon, 3 Nov 2025 10:34:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error :
>> `
>> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr`
>> 
>> instead we see in the log e.g. :
>> `Java Heap (reserved=67584KB, committed=65536KB)`
>> 
>> so it looks like adding asan to the build changes those memory values a bit.
>> We should disable this test when using asan enabled binaries .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable only little test part in case of asan

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/28055#issuecomment-3484734468

From iklam at openjdk.org  Tue Nov  4 09:13:25 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 09:13:25 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
Message-ID: <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>

On Tue, 4 Nov 2025 09:01:36 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
>> 
>> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
>> 
>> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
>> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
>> 
>> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
>> 
>> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
>> 
>> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactored the various "match" methods in OutputAnalyzer; added tests; reverted changes in AccessZeroNKlassHitsProtectionZone.java

Hi Stefan, thanks for looking into this.

> So, I would prefer to see the following:
> 
> 1. Fix the title to indicate that your updating the OutputAnalyzer
> 2. Fix the summary that states that MULTILINE is needed to match over newlines
> 3. Introduce the new "find" function (or rename matches)
> 4. Add tests
> 5. Preferably, use one RFE for the above enhancements and Bug for the test failure

I fixed the title, updated the summary and added test cases.

I didn't use "find", as all the existing methods in OutputAnalyzer use "match".

The bug is in OutputAnalyzer only. The test case AccessZeroNKlassHitsProtectionZone.java is correct in its current form. So I will use this PR to fix `OutputAnalyzer.matches()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3484765891

From jsikstro at openjdk.org  Tue Nov  4 09:36:08 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 4 Nov 2025 09:36:08 GMT
Subject: RFR: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly [v2]
In-Reply-To: <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
 <o-aOpPmGl-G50R7LAHlQJc-5vAw1XhaW68TWK2aHLC0=.f94902b9-4398-4e2d-8dda-b9af5b7b9a2a@github.com>
Message-ID: <3kmX1JJfUgWP9xmQ_fv8utOuTMk0jm1xC_jvQbDT8mw=.bbe886d1-bead-4429-bc9a-20171c349e5b@github.com>

On Mon, 3 Nov 2025 10:34:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error :
>> `
>> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr`
>> 
>> instead we see in the log e.g. :
>> `Java Heap (reserved=67584KB, committed=65536KB)`
>> 
>> so it looks like adding asan to the build changes those memory values a bit.
>> We should disable this test when using asan enabled binaries .
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disable only little test part in case of asan

Looks good.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28055#pullrequestreview-3415112379

From duke at openjdk.org  Tue Nov  4 09:47:39 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 4 Nov 2025 09:47:39 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v2]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <TdzU81Zpb9mxUTlvym_vleBjePgQ_YAL-FU0ZLUGk3g=.f221dbb3-01ad-49a8-86ab-1de081c0ca44@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Removed incorrect assert,
 - 8366659: Fixed merge conflict
 - 8366659: Fixed whitespace.
 - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - ... and 6 more: https://git.openjdk.org/jdk/compare/ef464d69...ba667e37

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=01
  Stats: 374 lines in 3 files changed: 310 ins; 44 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From duke at openjdk.org  Tue Nov  4 09:50:35 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 4 Nov 2025 09:50:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v3]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <2o8megr_K4HfeERT_OCCD4zQz0OLjtd9sQafi5btuSw=.2d1281cf-8965-41ba-97b6-e89466386664@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Added a comment to a boolean arg for enter()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/ba667e37..e84dca9d

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

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

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

From mbaesken at openjdk.org  Tue Nov  4 09:57:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Nov 2025 09:57:48 GMT
Subject: Integrated: 8364741: [asan]
 runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs
 slightly
In-Reply-To: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
References: <GxtJz9cegjcAMyWJwx4smWh3W89XrCltvqjWAgc-dVE=.a165aa42-7f03-48fd-b9e8-c5ca58c0ee16@github.com>
Message-ID: <m2d23zScg5Ex_h3sqs-k04OVUPwE4BzU3UyWFj2k8sw=.f033af9c-75a7-4b5a-9154-c52642ed02ba@github.com>

On Thu, 30 Oct 2025 09:24:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When running the test runtime/ErrorHandling/PrintVMInfoAtExitTest.java with asan enabled binaries on Linux x86_64, we fail with this error :
> `
> java.lang.RuntimeException: 'Java Heap (reserved=65536KB, committed=65536KB)' missing from stdout/stderr`
> 
> instead we see in the log e.g. :
> `Java Heap (reserved=67584KB, committed=65536KB)`
> 
> so it looks like adding asan to the build changes those memory values a bit.
> We should disable this test when using asan enabled binaries .

This pull request has now been integrated.

Changeset: a840dc22
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a840dc22c575b5d2b5b6017a536a6541fc1f0a44
Stats:     13 lines in 1 file changed: 11 ins; 0 del; 2 mod

8364741: [asan] runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails because output differs slightly

Reviewed-by: syan, phubner, jsikstro

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

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

From stefank at openjdk.org  Tue Nov  4 10:08:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 4 Nov 2025 10:08:46 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
Message-ID: <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>

On Tue, 4 Nov 2025 09:10:17 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I didn't use "find", as all the existing methods in OutputAnalyzer use "match".

My point is that you can't have a function called "matches" that performs a "find" instead of a "matches":

    private boolean matchesHelper(String s, Pattern pattern) {
        return s != null && pattern.matcher(s).find();
    }


That's too confusing.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3485047638

From jsjolen at openjdk.org  Tue Nov  4 10:27:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:27:07 GMT
Subject: RFR: 8369622: GlobalChunkPoolMutex needs to be recursive [v3]
In-Reply-To: <cTP-BcoQimnBcwHBXryTjrmCU1A04uPmeK8RGiRZdEg=.3cacb77e-b0a0-4ad0-bb3b-4cf93e3f4a00@github.com>
References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com>
 <cTP-BcoQimnBcwHBXryTjrmCU1A04uPmeK8RGiRZdEg=.3cacb77e-b0a0-4ad0-bb3b-4cf93e3f4a00@github.com>
Message-ID: <YgI9eAu05YYY4oo87tBoF1OstKI_3h0TzToZL2Vp_gY=.bde88d20-968e-4e77-a3b1-bf420c003dd0@github.com>

On Thu, 16 Oct 2025 13:21:41 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this.
>> 
>> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented.
>> 
>> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert access modifier style

Thanks for taking care of this while I was gone, Coleen! And sorry for not closing it before I went away, I didn't think about the confusion that it would cause.

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

PR Comment: https://git.openjdk.org/jdk/pull/27759#issuecomment-3485140374

From jsjolen at openjdk.org  Tue Nov  4 10:27:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 4 Nov 2025 10:27:09 GMT
Subject: Withdrawn: 8369622: GlobalChunkPoolMutex needs to be recursive
In-Reply-To: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com>
References: <4HTV9ShwndrYG3aVatlFlt5JNGlz3hJJmxI6hNjFGB0=.8b6a7f18-63ea-4fa6-9823-2196ec923802@github.com>
Message-ID: <ZJE5JwGk5A3Ea_mpvUBr0Gcw46oBpMj3BSiFNfkjMH4=.70dfff5f-c5f0-4b81-ab9d-2d9c599f1eae@github.com>

On Sun, 12 Oct 2025 12:55:53 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> The GlobalChunkPoolMutex replaced ThreadCritical in [JDK-8356173](https://bugs.openjdk.org/browse/JDK-8356173). In NMT, we can unfortunately reach a recursive locking situation in situations when the VM is crashing and NMT attempts to perform a error report. I suggest that we make this particular mutex recursive, until we can resolve the design issues that causes this.
> 
> This PR also replaces the static initialization with `DeferredStatic`, and fixes the indentation of access modifiers to be consistently 0-indented.
> 
> Please note that we do not take the lock in NMT in order to allocate memory, but in order to have a "static picture" of the arena counters.

This pull request has been closed without being integrated.

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

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

From phubner at openjdk.org  Tue Nov  4 11:02:28 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 11:02:28 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>

On Sun, 2 Nov 2025 06:27:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

>From the manpage:
> The name of the vDSO varies across architectures.  It will often
       show up in things like glibc's [ldd(1)](https://man7.org/linux/man-pages/man1/ldd.1.html) output.  The exact name
       should not matter to any code, so do not hardcode it.
       
Just throwing an idea out there, since we are hardcoding the name, would it be worth to add an `else` clause to your `if`, in which we `assert` that `filepath` does not contain `vdso` or `linux-gate.so`?

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

PR Review: https://git.openjdk.org/jdk/pull/28102#pullrequestreview-3415738465

From stuefe at openjdk.org  Tue Nov  4 11:45:49 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Nov 2025 11:45:49 GMT
Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365
In-Reply-To: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
References: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
Message-ID: <GkPfszg1zsOnhJmjUrBisFydIm6K5F7Rt9hSDBHAbHM=.ef7d05cf-97e1-4e88-8367-ad9623db35c4@github.com>

On Thu, 30 Oct 2025 10:48:11 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Added a missed header file and fixed copyright year.
> Tested on macosx-aarch64 ASAN build.

all good.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28058#pullrequestreview-3416010604

From stuefe at openjdk.org  Tue Nov  4 11:45:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 4 Nov 2025 11:45:51 GMT
Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365
In-Reply-To: <zk3XcjDE7KTjfPfUaHyXMV9pgjHrfSgYQBn-BFpLjmw=.ec2493aa-e6a0-4550-8ece-de0669667777@github.com>
References: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
 <B3epdaa0ne5w2a51gXlgnUCePB5SJ-zEjhdWWVra6ow=.b50e6cb7-7ca4-46de-b738-3456b8b6b367@github.com>
 <zk3XcjDE7KTjfPfUaHyXMV9pgjHrfSgYQBn-BFpLjmw=.ec2493aa-e6a0-4550-8ece-de0669667777@github.com>
Message-ID: <gy0HDjnx4tEzMzShF9KX7pK8LLLUXeh2AasZBRvRhp0=.fcf9e7bd-daac-49a2-9b37-396ca3aa8f85@github.com>

On Fri, 31 Oct 2025 07:33:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/sanitizers/address.cpp line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> Please keep it as it is.
>> 
>> `XX, YY` means that this file was created at `XX` year and lastly updated at `YY` year. If `XX == YY` then use `XX`.
>
> This file was added by https://github.com/openjdk/jdk/pull/27446 with this copyright notice, but there is no indication that any of the content was copied from elsewhere from a file with the 1998 copyright notice, in which case it should not be present. Maybe @tstuefe will notice this and comment on that.

No, @afshin-zafari was right, this was an oversight of me. The fix is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28058#discussion_r2490190278

From iklam at openjdk.org  Tue Nov  4 11:52:10 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 11:52:10 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v3]
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <0shDJhw9EZOwTC8r9telIA99KVqSDjNJR44azwaunNU=.1d171e95-323b-42aa-8f39-9c0768a76283@github.com>

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
> 
> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
> 
> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
> 
> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
> 
> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Renamed matchesHelper() to findPattern()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28077/files
  - new: https://git.openjdk.org/jdk/pull/28077/files/3b493855..b3feafc5

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

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

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

From iklam at openjdk.org  Tue Nov  4 11:56:52 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 11:56:52 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
> 
> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
> 
> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
> 
> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
> 
> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Use String... as suggested by @stefank

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28077/files
  - new: https://git.openjdk.org/jdk/pull/28077/files/b3feafc5..c0f37497

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

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

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

From iklam at openjdk.org  Tue Nov  4 11:56:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 11:56:53 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
 <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
Message-ID: <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>

On Tue, 4 Nov 2025 10:05:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > I didn't use "find", as all the existing methods in OutputAnalyzer use "match".
> 
> My point is that you can't have a function called "matches" that performs a "find" instead of a "matches":
> 
> ```
>     private boolean matchesHelper(String s, Pattern pattern) {
>         return s != null && pattern.matcher(s).find();
>     }
> ```
> 
> That's too confusing.

Thanks for the clarification. I've updated the code using your suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3485603985

From ysuenaga at openjdk.org  Tue Nov  4 12:21:02 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 4 Nov 2025 12:21:02 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
 <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>
Message-ID: <9q6sEvrBzhWLGSnGHWkfZrKcfFea-mQ3MZknTI4-RAU=.16b44786-4e12-4175-8963-196315f7cfba@github.com>

On Tue, 4 Nov 2025 11:00:03 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> would it be worth to add an else clause to your if, in which we assert that filepath does not contain vdso or linux-gate.so?

It would be false-positive if "vdso" is included unintended path like "libfoo-vdsoon.so" . `linux-gate.so` is for unsupported platform of OpenJDK e.g. IA64, SH.

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3485695366

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 phubner at openjdk.org  Tue Nov  4 12:50:36 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 4 Nov 2025 12:50:36 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <9q6sEvrBzhWLGSnGHWkfZrKcfFea-mQ3MZknTI4-RAU=.16b44786-4e12-4175-8963-196315f7cfba@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
 <E0D2wRDoc6qRw5OFTqUQazZSpPlTo5NWNnOG_4zCPxc=.eb9f28b6-8de7-4dc4-9359-16f4940556a6@github.com>
 <9q6sEvrBzhWLGSnGHWkfZrKcfFea-mQ3MZknTI4-RAU=.16b44786-4e12-4175-8963-196315f7cfba@github.com>
Message-ID: <RMQFXYcczF2nYMrGfaMbAaJiI9LA1_9ONUylaZiraS4=.ce2c7cfe-8485-4f5f-9656-404bfce8dca2@github.com>

On Tue, 4 Nov 2025 12:18:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > would it be worth to add an else clause to your if, in which we assert that filepath does not contain vdso or linux-gate.so?
> 
> It would be false-positive if "vdso" is included unintended path like "libfoo-vdsoon.so" . `linux-gate.so` is for unsupported platform of OpenJDK e.g. IA64, SH.

Yes, it would be a false positive. If I understand correctly, right now we error due to an assertion. So after your patch, if someone (for whatever reason) has a different file name, we would error anyway in the same way we error now, via the same assertion right? If we error anyway, feel like it could be marginally more helpful to make the error location/message as precise as possible.

That said, I don't know this area nor vDSO very well, so I'm not sure if my proposal is very canonical. I'm just brainstorming from the perspective of someone who wants to make debugging as straightforward as possible. I'm happy to approve the change as-is. What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3485834347

From stefank at openjdk.org  Tue Nov  4 13:47:11 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 4 Nov 2025 13:47:11 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
 <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
 <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>
Message-ID: <-6jxu9IZk1e4HkuhLC7s6ukT2ZvaGyOhOmy0u6fFomk=.c72390c0-7422-4e63-80f4-0a5d0e5b09dd@github.com>

On Tue, 4 Nov 2025 11:53:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > I didn't use "find", as all the existing methods in OutputAnalyzer use "match".
> > 
> > 
> > My point is that you can't have a function called "matches" that performs a "find" instead of a "matches":
> > ```
> >     private boolean matchesHelper(String s, Pattern pattern) {
> >         return s != null && pattern.matcher(s).find();
> >     }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > That's too confusing.
> 
> Thanks for the clarification. I've updated the code using your suggestion.

You need to make sure that the code has sensible throughout the library, not only the functions you introduce. There's still a function that uses "find" that has a name including "matches":

    public boolean stdoutMatches(String regexp) {
        return findPattern(regexp, getStdout());
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3486079517

From ysuenaga at openjdk.org  Tue Nov  4 13:51:29 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 4 Nov 2025 13:51:29 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <RhJ6KZBhWqUvLDuixKqLBQBpHD1hm0J-ucKMaLaMaP0=.2ce8d608-ca8c-4ab4-b01b-7a26529862a8@github.com>

On Sun, 2 Nov 2025 06:27:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

vDSO is very special, it is a part of kernel, we can't find the .so file on lib directory (e.g. `/usr/lib64`).

The assertion mentioned this issue is caused by this behavior - `ElfDecorder` attemps to load souce information from ELF, but it wouldn't because vDSO file is not found. It should happen on vDSO because regular loaded ELFs should be located on file system (otherwise the process wouldn't load library of course).

vDSO name is specified in manpage, so we can skip vDSO only. Thus I think it does not need to add `else` for other files named with `vdso`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3486093770

From iklam at openjdk.org  Tue Nov  4 16:24:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 16:24:47 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v2]
In-Reply-To: <-6jxu9IZk1e4HkuhLC7s6ukT2ZvaGyOhOmy0u6fFomk=.c72390c0-7422-4e63-80f4-0a5d0e5b09dd@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <_uOJSWcFm1iTKhiysbRiefQQzs4WHmrOgS-gBmbmKXM=.6277cce1-aee5-44f2-bd40-5512103c55e5@github.com>
 <1w9gNknsXK62jGJ9-9MP-LiVVucAGS5vj_BnNVoHz2U=.1ee7969f-70c9-46b7-95c8-ef35b0e99490@github.com>
 <G2x2_2KA2PbbmCtnAw2aLTytET2zDjF7nivP6RQIrkE=.3232f3ef-f6cf-429a-a284-307978e7d05d@github.com>
 <4uF7j8nhnIoLoEwu-FH8OESbXR6bprJgxdZZME-Kbik=.e76d884b-3519-465c-aed6-16d457026d2d@github.com>
 <-6jxu9IZk1e4HkuhLC7s6ukT2ZvaGyOhOmy0u6fFomk=.c72390c0-7422-4e63-80f4-0a5d0e5b09dd@github.com>
Message-ID: <EyOHsmC5aW8d5de4cGo4xT7DESDjbtN6oVXc2Xa3yL8=.6ebed0ab-e862-431b-b3f3-afb6ab35f08f@github.com>

On Tue, 4 Nov 2025 13:44:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> You need to make sure that the code has sensible names throughout the library, not only the functions you introduce. There are still functions that uses "find" that have names that including the word "matches":
> 
> ```
>     public boolean stdoutMatches(String regexp) {
>         return findPattern(regexp, getStdout());
>     }
> ```

We have existing APIs like `contains()` vs `shouldContain()`. If I introduce a new API `finds()`, that will be inconsistent with `shouldMatch()`.

There are hundreds of `shouldMatch()` in existing tests, and honestly "matching a regexp" is more intuitive than "finding a substring that matches the regexp", so I don't see any reason of changing that.

So, we will inevitably have an API with the name `match` that eventually calls "...matcher().find()". It's still using a "matcher" to decides whether something "matches". I don't see a problem with doing this, especially when it's only used in the implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3486861935

From duke at openjdk.org  Tue Nov  4 16:31:05 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 16:31:05 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v2]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <1azA71s8sFRamYweW9fbMEv1Drl2dNVUT7qZmUPeQeU=.c9bbf5eb-fede-44ae-b767-549a74a5dd75@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai 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 10 additional commits since the last revision:

 - Merge branch 'openjdk:master' into macos-vm-tagging
 - 1. Test improved to incorporate os/zgc allocation routines 2. Minor refactor to improve readability
 - remove extra whitespace
 - remove extra whitespace
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Covered ZGC direct mmap usage for JAVA tagging. Added unit test to validate changes
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Merge branch 'openjdk:master' into macos-vm-tagging
 - Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/1144ca92..1c8b3818

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

  Stats: 73212 lines in 988 files changed: 39905 ins; 27282 del; 6025 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From iklam at openjdk.org  Tue Nov  4 16:41:57 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 16:41:57 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
In-Reply-To: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
Message-ID: <8jLMc6gqfaM571wCE9s8YMsDDc37GZIRNHzBmmsC6bw=.b5e016a5-283f-4788-9350-d5cb0b1dca3e@github.com>

On Tue, 4 Nov 2025 02:10:13 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
> 
> Testing:
> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64

src/hotspot/share/cds/aotMetaspace.cpp line 556:

> 554:         case ztos:
> 555:           new_code = Bytecodes::_fast_bgetfield;
> 556:           break;

Why is this `switch` block necessary? Is it possible for `new_code` to be different than `*bcs.bcp()`? If not, it might be easier to initialize `new_code` to `Bytecodes::_illegal` and then do the rewriting only if `new_code` has been updated.

src/hotspot/share/cds/aotMetaspace.cpp line 635:

> 633:     }
> 634:     case Bytecodes::_aload_0:
> 635:       new_code = Bytecodes::_nofast_aload_0;

Maybe add a comment here that `_fast_Xaccess_0` bytecodes will be reverted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28121#discussion_r2491222034
PR Review Comment: https://git.openjdk.org/jdk/pull/28121#discussion_r2491238312

From duke at openjdk.org  Tue Nov  4 16:46:28 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 16:46:28 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v3]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  clean whitespaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/1c8b3818..72a6e5fb

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

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

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

From henryjen at openjdk.org  Tue Nov  4 17:00:02 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 4 Nov 2025 17:00:02 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
 [v2]
In-Reply-To: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
Message-ID: <a__MN_-K_Q5kCcgrJQRWXueVSte1VJ3lmK-RuZDKVuo=.7bc30023-288b-4a14-b1ff-ccf3b8705a6d@github.com>

> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Explicitly initialize location

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28098/files
  - new: https://git.openjdk.org/jdk/pull/28098/files/27208690..f1a7f807

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

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

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

From henryjen at openjdk.org  Tue Nov  4 17:00:03 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 4 Nov 2025 17:00:03 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
In-Reply-To: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
Message-ID: <e3qXX_ldJ6x5VwB-WKWUHI83w-lWVY1kDISPym5-XgA=.231775a4-5e4a-42ab-ab41-bbc6740840db@github.com>

On Sat, 1 Nov 2025 15:42:37 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.

I ran tier1 to tier5, all seems good. There are two post-execution errors regarding to artifactory not related to the code change.

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

PR Comment: https://git.openjdk.org/jdk/pull/28098#issuecomment-3487037390

From asmehra at openjdk.org  Tue Nov  4 17:04:42 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Tue, 4 Nov 2025 17:04:42 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
In-Reply-To: <8jLMc6gqfaM571wCE9s8YMsDDc37GZIRNHzBmmsC6bw=.b5e016a5-283f-4788-9350-d5cb0b1dca3e@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <8jLMc6gqfaM571wCE9s8YMsDDc37GZIRNHzBmmsC6bw=.b5e016a5-283f-4788-9350-d5cb0b1dca3e@github.com>
Message-ID: <3ZnhVZcUy-Rcd-RJUyhZUdngWOT0Cfnb_RgLF99wsOs=.5f7b4815-7955-4625-9ba3-c3592999a353@github.com>

On Tue, 4 Nov 2025 16:32:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Why is this switch block necessary? Is it possible for new_code to be different than *bcs.bcp()?

During preimage dumping all the fast bytecodes will be converted to nofast version because the CP entries are not resolved. So in the assembly phase `*bcs.bcp()` would be nofast version. If the CP entry is resolved, we can convert it to fast version. And we determine the type of the fast version using `tos_state` of the resolved field entry. So the `new_code` will be different than the `*bcs.bcp()` in the assembly phase.
They may be same when dumping dynamic archives, but not when dumping static archive or the final AOTCache.
Does that help?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28121#discussion_r2491336315

From stefank at openjdk.org  Tue Nov  4 17:06:52 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 4 Nov 2025 17:06:52 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v3]
In-Reply-To: <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>
Message-ID: <jUn0HlN35ZQXg6QtqRng3X9BPjq8K81b22qEYl0gEkA=.bd3339e1-f958-4a6e-9422-850f7c21ce15@github.com>

On Tue, 4 Nov 2025 16:46:28 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean whitespaces

EOD here but got notified about this change. A few quick comments:
1) Could you fix the whitespace issues GH is complaining about?
2) There's a significant amount of duplication of these conspicuous additions. Could you you create a constexpr function and use that instead?
3) It doesn't seem prudent to put the new testing code in our test_zForwarding.cpp file. Could this be in its own test file?

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3417654140

From duke at openjdk.org  Tue Nov  4 17:12:15 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 17:12:15 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v4]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <Fnnb6wAFEBUYDZekKd6vSxLTSylDGZA0WCjUnxuEiJ8=.baf637fb-b65f-46e2-a1a6-d966491a3cca@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  more whitespace cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/72a6e5fb..ab1a90d0

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

  Stats: 17 lines in 3 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From iklam at openjdk.org  Tue Nov  4 17:33:33 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 17:33:33 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
In-Reply-To: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
Message-ID: <4FbpXh74PxIG8rjqgnsULuGHAFe5pe5QpYgx5YCfw6k=.fed2717f-8373-4227-aaf4-99e1a4c72765@github.com>

On Tue, 4 Nov 2025 02:10:13 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
> 
> Testing:
> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64

src/hotspot/share/cds/aotMetaspace.cpp line 549:

> 547:       }
> 548: #endif // ASSERT
> 549:       if (is_resolved) {

I think the above can be simplified:


if (is_resolved) {
  assert(!CDSConfig::is_dumping_preimage_static_archive(), "preimage should not have resolved field references");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28121#discussion_r2491457985

From iklam at openjdk.org  Tue Nov  4 17:33:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 4 Nov 2025 17:33:38 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
In-Reply-To: <3ZnhVZcUy-Rcd-RJUyhZUdngWOT0Cfnb_RgLF99wsOs=.5f7b4815-7955-4625-9ba3-c3592999a353@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <8jLMc6gqfaM571wCE9s8YMsDDc37GZIRNHzBmmsC6bw=.b5e016a5-283f-4788-9350-d5cb0b1dca3e@github.com>
 <3ZnhVZcUy-Rcd-RJUyhZUdngWOT0Cfnb_RgLF99wsOs=.5f7b4815-7955-4625-9ba3-c3592999a353@github.com>
Message-ID: <bu-L44jHHeHLdxJMCB0dvWhWIp2XVbBw2Slb3z6J4Lc=.ffe6b54d-d273-4d04-85ee-f3366118e471@github.com>

On Tue, 4 Nov 2025 17:02:21 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/share/cds/aotMetaspace.cpp line 556:
>> 
>>> 554:         case ztos:
>>> 555:           new_code = Bytecodes::_fast_bgetfield;
>>> 556:           break;
>> 
>> Why is this `switch` block necessary? Is it possible for `new_code` to be different than `*bcs.bcp()`? If not, it might be easier to initialize `new_code` to `Bytecodes::_illegal` and then do the rewriting only if `new_code` has been updated.
>
>> Why is this switch block necessary? Is it possible for new_code to be different than *bcs.bcp()?
> 
> During preimage dumping all the fast bytecodes will be converted to nofast version because the CP entries are not resolved. So in the assembly phase `*bcs.bcp()` would be nofast version. If the CP entry is resolved, we can convert it to fast version. And we determine the type of the fast version using `tos_state` of the resolved field entry. So the `new_code` will be different than the `*bcs.bcp()` in the assembly phase.
> They may be same when dumping dynamic archives, but not when dumping static archive or the final AOTCache.
> Does that help?

I see. Could you add a comment? Maybe the code should be reformatted like this to make it easier to navigate?


        case ftos:  new_code = Bytecodes::_fast_fgetfield;  break;
        case dtos: new_code = Bytecodes::_fast_dgetfield; break;
        default:  ShouldNotReachHere();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28121#discussion_r2491446913

From duke at openjdk.org  Tue Nov  4 18:24:01 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 18:24:01 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v5]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <O4fmoZMVCIiQ1ERVR_tze14dkLZSrsif0Ce_51BVh1w=.503e2102-5cde-40f1-b323-8b731a8a17c1@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  move is_memory_tagged_as_java to common to reduce duplication

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/ab1a90d0..2322badf

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

  Stats: 122 lines in 4 files changed: 43 ins; 74 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From darcy at openjdk.org  Tue Nov  4 18:47:51 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Nov 2025 18:47:51 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <4YP2knvpGm61PssS9EtEX4W35vd90XLOjgkevNqaBF0=.e5a34d1c-4f3d-407e-b53d-789a97682a0d@github.com>

On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Get JDK 27 underway.

Looks fine so far.

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

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3418178547

From duke at openjdk.org  Tue Nov  4 19:07:32 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 19:07:32 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  minor refactoring to reduce code duplication

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/2322badf..183927b0

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

  Stats: 42 lines in 3 files changed: 12 ins; 24 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Tue Nov  4 19:07:33 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Tue, 4 Nov 2025 19:07:33 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v3]
In-Reply-To: <jUn0HlN35ZQXg6QtqRng3X9BPjq8K81b22qEYl0gEkA=.bd3339e1-f958-4a6e-9422-850f7c21ce15@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <Lf8ue6xAJxE6JJ5ZaUsp8zrMJ5jZbcNS5rCBtwFGTH4=.26a219d3-f2ac-49ce-8341-743f3b7a3fb4@github.com>
 <jUn0HlN35ZQXg6QtqRng3X9BPjq8K81b22qEYl0gEkA=.bd3339e1-f958-4a6e-9422-850f7c21ce15@github.com>
Message-ID: <ig2LWccxlfmDTtghCPT1IKJSJzfPQ1c0_Gz_j9hYmXk=.e50e6fc5-3d03-485e-8d07-caeabf6c8429@github.com>

On Tue, 4 Nov 2025 17:03:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> EOD here but got notified about this change. A few quick comments:
> 
> 1. Could you fix the whitespace issues GH is complaining about?
Fixed
> 2. There's a significant amount of duplication of these conspicuous additions. Could you you create a constexpr function and use that instead?
Refactored code to remove duplication.
> 3. It doesn't seem prudent to put the new testing code in our test_zForwarding.cpp file. Could this be in its own test file?
I think the changes are minor to assert the tagging on allocation while we are doing that and do not require extra tests, please let me know if you still think otherwise.

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

PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3487603064

From matsaave at openjdk.org  Tue Nov  4 19:25:48 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Tue, 4 Nov 2025 19:25:48 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code
Message-ID: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>

There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.

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

Commit messages:
 - 8272160: Avoid using 32-bit counters in CDS code

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

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

From nbenalla at openjdk.org  Tue Nov  4 20:11:23 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Nov 2025 20:11:23 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v2]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <3cZuldBvytdN_Hu0qlLhUkrCsH5EUlZJ5SEjnF8SLEU=.e76693bd-f6e1-4f8a-9dd5-699c9e4306bf@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  add missing enum

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/cc1a968e..647904b3

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

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

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

From kvn at openjdk.org  Tue Nov  4 20:21:50 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 4 Nov 2025 20:21:50 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code
In-Reply-To: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
Message-ID: <fMUFwCmnI2UHRCn25-Qi2a2cGSH-4-GSeeVbMeagVZc=.2b4bffcd-451b-4918-b5af-c5b2a4afa541@github.com>

On Tue, 4 Nov 2025 19:08:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.

You only changed `CountSharedSymbols::_count`. Please, adjust RFE's title accordingly.

I am not actually convinced why it is necessary. Can you explain why? What benefits you get with this change.

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

PR Review: https://git.openjdk.org/jdk/pull/28139#pullrequestreview-3418498865

From nbenalla at openjdk.org  Tue Nov  4 20:24:52 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 4 Nov 2025 20:24:52 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v3]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <Tk-NvGBIdEw-6vRKcbJD0hfB-q3Zzu8hTsrk9w_yQbQ=.553395d1-799c-4390-93f1-d5f9bb058f05@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  update links to JVMS 26 and 27

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/647904b3..b51f2324

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

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

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

From asmehra at openjdk.org  Wed Nov  5 01:33:39 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 01:33:39 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache [v2]
In-Reply-To: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
Message-ID: <hISQ7zrsj2bxIqXy6bRSraeJwm2I4XQyZI8ZQL9Jkw8=.4fa23593-91b0-46c3-a5b5-4085076ef915@github.com>

> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
> 
> Testing:
> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28121/files
  - new: https://git.openjdk.org/jdk/pull/28121/files/a5fd053b..40430e3c

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

  Stats: 80 lines in 3 files changed: 14 ins; 44 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/28121.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28121/head:pull/28121

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

From asmehra at openjdk.org  Wed Nov  5 01:33:41 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 01:33:41 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
In-Reply-To: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
Message-ID: <_Oeu3ng6OUg9LCM6vNSqduUr6z9XFnz6VdF_U_26SCE=.5dce3c5a-ddde-4eee-9900-767372f50d9b@github.com>

On Tue, 4 Nov 2025 02:10:13 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
> 
> Testing:
> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64

@iklam addressed the review comments in the new commit. I also updated function names to remove "nofast" to better reflect the updates to their functionality.

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

PR Comment: https://git.openjdk.org/jdk/pull/28121#issuecomment-3488706605

From asmehra at openjdk.org  Wed Nov  5 01:33:45 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 01:33:45 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache [v2]
In-Reply-To: <4FbpXh74PxIG8rjqgnsULuGHAFe5pe5QpYgx5YCfw6k=.fed2717f-8373-4227-aaf4-99e1a4c72765@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <4FbpXh74PxIG8rjqgnsULuGHAFe5pe5QpYgx5YCfw6k=.fed2717f-8373-4227-aaf4-99e1a4c72765@github.com>
Message-ID: <dwhpAAIhoqAcl5tc2-ZM9UrZ7-d7iT_MSKuIwFszBT4=.13999463-709c-4ef1-bb0a-ab338dc10cd2@github.com>

On Tue, 4 Nov 2025 17:30:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> src/hotspot/share/cds/aotMetaspace.cpp line 549:
> 
>> 547:       }
>> 548: #endif // ASSERT
>> 549:       if (is_resolved) {
> 
> I think the above can be simplified:
> 
> 
> if (is_resolved) {
>   assert(!CDSConfig::is_dumping_preimage_static_archive(), "preimage should not have resolved field references");

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28121#discussion_r2492505902

From asmehra at openjdk.org  Wed Nov  5 01:33:47 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 01:33:47 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache [v2]
In-Reply-To: <bu-L44jHHeHLdxJMCB0dvWhWIp2XVbBw2Slb3z6J4Lc=.ffe6b54d-d273-4d04-85ee-f3366118e471@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <8jLMc6gqfaM571wCE9s8YMsDDc37GZIRNHzBmmsC6bw=.b5e016a5-283f-4788-9350-d5cb0b1dca3e@github.com>
 <3ZnhVZcUy-Rcd-RJUyhZUdngWOT0Cfnb_RgLF99wsOs=.5f7b4815-7955-4625-9ba3-c3592999a353@github.com>
 <bu-L44jHHeHLdxJMCB0dvWhWIp2XVbBw2Slb3z6J4Lc=.ffe6b54d-d273-4d04-85ee-f3366118e471@github.com>
Message-ID: <v8gGMRH8-8fRhULSFC-avQTgMGgIyb-0xATWuSc4oEM=.6c8cfb12-2143-42b7-b912-8a2fed5e7b70@github.com>

On Tue, 4 Nov 2025 17:28:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> Why is this switch block necessary? Is it possible for new_code to be different than *bcs.bcp()?
>> 
>> During preimage dumping all the fast bytecodes will be converted to nofast version because the CP entries are not resolved. So in the assembly phase `*bcs.bcp()` would be nofast version. If the CP entry is resolved, we can convert it to fast version. And we determine the type of the fast version using `tos_state` of the resolved field entry. So the `new_code` will be different than the `*bcs.bcp()` in the assembly phase.
>> They may be same when dumping dynamic archives, but not when dumping static archive or the final AOTCache.
>> Does that help?
>
> I see. Could you add a comment? Maybe the code should be reformatted like this to make it easier to navigate?
> 
> 
>         case ftos:  new_code = Bytecodes::_fast_fgetfield;  break;
>         case dtos: new_code = Bytecodes::_fast_dgetfield; break;
>         default:  ShouldNotReachHere();

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28121#discussion_r2492505638

From jsjolen at openjdk.org  Wed Nov  5 05:09:16 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Nov 2025 05:09:16 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
Message-ID: <Dg5ZqTZIs7F6FFD0xk5uDz2b7Tzn42tgUxV26lP7xXs=.503c6bc4-2d21-42fb-a5aa-43125d2d32c7@github.com>

On Tue, 4 Nov 2025 19:07:32 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring to reduce code duplication

Changes requested by jsjolen (Reviewer).

test/hotspot/gtest/runtime/test_os.cpp line 744:

> 742:     EXPECT_TRUE(GtestUtils::is_memory_tagged_as_java(p, 1 * M))
> 743:       << "JVM memory allocated via os::reserve_memory should be tagged with VM_MEMORY_JAVA on macOS";
> 744: #endif

Move all of these snippets into one separate test

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

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3419863275
PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2492971686

From mbaesken at openjdk.org  Wed Nov  5 08:50:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 5 Nov 2025 08:50:20 GMT
Subject: RFR: 8354937: Cleanup some sparc related coding in os_linux
Message-ID: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>

There is still some SPARC related coding remaining in os_linux, but we do not support Linux on SPARC for quite some time.

(there is more SPARC coding for detecting Sparc shared libs but I kept, that for now; not sure how important this is these days see https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L1762  )

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

Commit messages:
 - JDK-8354937

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

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

From azafari at openjdk.org  Wed Nov  5 08:57:14 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 5 Nov 2025 08:57:14 GMT
Subject: RFR: 8370874: [asan] ASAN build fails after JDK-8368365
In-Reply-To: <XeLQ6PRNZdbtlxvyC0XKhk9PQpwcoTpSUiXurEKrs_k=.a7337e9f-a43e-4cd3-9431-2f404b838dfb@github.com>
References: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
 <XeLQ6PRNZdbtlxvyC0XKhk9PQpwcoTpSUiXurEKrs_k=.a7337e9f-a43e-4cd3-9431-2f404b838dfb@github.com>
Message-ID: <YVL7DQGltKEj4j-kPGq38LuHHupSKVCTTfwOYxwU_8w=.bb736315-deb4-4512-a96b-6691694db265@github.com>

On Fri, 31 Oct 2025 07:33:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Added a missed header file and fixed copyright year.
>> Tested on macosx-aarch64 ASAN build.
>
> Marked as reviewed by dholmes (Reviewer).

Thank you @dholmes-ora , @tstuefe and @shqking for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28058#issuecomment-3490002292

From azafari at openjdk.org  Wed Nov  5 09:00:31 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 5 Nov 2025 09:00:31 GMT
Subject: Integrated: 8370874: [asan] ASAN build fails after JDK-8368365
In-Reply-To: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
References: <kvcqM0xjfIzzvkfI8cwGWZRpzwHiAXRwX_up2dqzkLg=.a8b2500c-3cf3-4a1d-8e62-232f81113c9c@github.com>
Message-ID: <P52Ms5KcmYI46DWctF53gnI52xspOVH5Bct3cvGHWwM=.328502d5-24a2-4d9f-bf81-57175b499b91@github.com>

On Thu, 30 Oct 2025 10:48:11 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Added a missed header file and fixed copyright year.
> Tested on macosx-aarch64 ASAN build.

This pull request has now been integrated.

Changeset: f5d8bd0d
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5d8bd0dd50bcd963b4062997aecb4e15249e30d
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8370874: [asan] ASAN build fails after JDK-8368365

Reviewed-by: haosun, dholmes, syan, stuefe

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

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

From adinn at openjdk.org  Wed Nov  5 09:22:47 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 5 Nov 2025 09:22:47 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache [v2]
In-Reply-To: <hISQ7zrsj2bxIqXy6bRSraeJwm2I4XQyZI8ZQL9Jkw8=.4fa23593-91b0-46c3-a5b5-4085076ef915@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <hISQ7zrsj2bxIqXy6bRSraeJwm2I4XQyZI8ZQL9Jkw8=.4fa23593-91b0-46c3-a5b5-4085076ef915@github.com>
Message-ID: <Iq0gvwVzxObKh3GnZaPCGSQofBIxybMScdNs9TKTHpE=.86a4e6fd-ba47-49dc-a8f6-a380dc178e01@github.com>

On Wed, 5 Nov 2025 01:33:39 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
>> 
>> Testing:
>> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Marked as reviewed by adinn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28121#pullrequestreview-3420755905

From jsjolen at openjdk.org  Wed Nov  5 09:29:00 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Nov 2025 09:29:00 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v16]
In-Reply-To: <DWvXEJ1vmq4z76zONCHQ2l6chiAK2B86GeqgkScQSAU=.1e7cb038-ecd0-420a-b814-ab268b0fde26@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <DWvXEJ1vmq4z76zONCHQ2l6chiAK2B86GeqgkScQSAU=.1e7cb038-ecd0-420a-b814-ab268b0fde26@github.com>
Message-ID: <fFD5QFu8N2bMfc1JVDm4Xx2hG3RCjMsxE3gTkm1heQQ=.0d37ce54-62a5-4b5d-a464-db2f29432293@github.com>

On Sat, 18 Oct 2025 17:26:26 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed problem after merge

Changes requested by jsjolen (Reviewer).

src/hotspot/share/nmt/mallocHeader.hpp line 91:

> 89:  */
> 90: 
> 91: 

Remove

src/hotspot/share/nmt/mallocHeader.hpp line 155:

> 153: 
> 154:   uint8_t* footer_address() const { return ((address)this) + sizeof(MallocHeader) + size(); }
> 155: 

Why is this moved to the public interface? If it's for the tests, then use a fixture class and a `friend class` declaration in `MallocHeader`.

src/hotspot/share/nmt/mallocHeader.hpp line 189:

> 187:     AsanPoisoningHelper aph(&_canary);
> 188:     return _canary;
> 189:   }

Why is this moved to the public interface?

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

PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3420743753
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2493630596
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2493643401
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2493641091

From jsjolen at openjdk.org  Wed Nov  5 09:29:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Nov 2025 09:29:03 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v7]
In-Reply-To: <o9n13ffy9-zfhaJ5GUAd6R5l483XPWdj9JSFOBUeoSg=.64b823ae-5a8b-40f9-8fa3-c780bc913042@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <uPUI0iuNOtY_mMUDAB4ZHVHYgitiA3eIRawjuqpMcsY=.ab7f61d6-e33e-4312-af25-b643ae670e1b@github.com>
 <czi20gtqU5KWXpQJyvAXYkkmIk_2ZeGx8Iqltnd3Ih8=.35ca01b5-683c-4d26-a5bb-6f9b70b04a19@github.com>
 <o9n13ffy9-zfhaJ5GUAd6R5l483XPWdj9JSFOBUeoSg=.64b823ae-5a8b-40f9-8fa3-c780bc913042@github.com>
Message-ID: <os-FO6DCeGitoJOKbbnAB8FyfUc5DUGzPr1qjvSx3B8=.9ad54f36-306e-4a5d-b2b8-f521b3eb6942@github.com>

On Tue, 14 Oct 2025 16:08:54 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/sanitizers/address.hpp line 29:
>> 
>>> 27: 
>>> 28: #ifdef ADDRESS_SANITIZER
>>> 29: #define __SANITIZE_ADDRESS__
>> 
>> Why not just check for `ADDRESS_SANITIZER` in the test, and skip this definition?
>
> In `.../clang/15.0.0/include/sanitizer/asan_interface.h`, the ASAN_(UN)POISON_MEMORY_REGION  macros would be empty as  
> ```C++
> // Macros provided for convenience.
> #if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
> /// Marks a memory region as unaddressable.
> ///
> /// \note Macro provided for convenience; defined as a no-op if ASan is not
> /// enabled.
> ///
> /// \param addr Start of memory region.
> /// \param size Size of memory region.
> #define ASAN_POISON_MEMORY_REGION(addr, size) \
>   __asan_poison_memory_region((addr), (size))
> 
> /// Marks a memory region as addressable.
> ///
> /// \note Macro provided for convenience; defined as a no-op if ASan is not
> /// enabled.
> ///
> /// \param addr Start of memory region.
> /// \param size Size of memory region.
> #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \
>   __asan_unpoison_memory_region((addr), (size))
> #else
> #define ASAN_POISON_MEMORY_REGION(addr, size) \
>   ((void)(addr), (void)(size))
> #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \
>   ((void)(addr), (void)(size))
> #endif
> 
> 
> I couldn't find yet why is that. So a fast/certain solution was to define the `__SANITIZE_ADDRESS__` explicitly.
> Should be found before integrating this PR.

@afshin-zafari , could you respond to this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2493646501

From ayang at openjdk.org  Wed Nov  5 10:41:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 5 Nov 2025 10:41:33 GMT
Subject: RFR: 8354937: Cleanup some sparc related coding in os_linux
In-Reply-To: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
References: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
Message-ID: <BVRlkVUCxYJNbSRL5Nwm3vq0Ryl5mV1AOC6k-w8yDoU=.d67ff956-3640-45c7-9b62-83df7cb1b515@github.com>

On Wed, 5 Nov 2025 08:42:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is still some SPARC related coding remaining in os_linux, but we do not support Linux on SPARC for quite some time.
> 
> (there is more SPARC coding for detecting Sparc shared libs but I kept, that for now; not sure how important this is these days see https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L1762  )

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28143#pullrequestreview-3421151409

From mdoerr at openjdk.org  Wed Nov  5 13:11:12 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 5 Nov 2025 13:11:12 GMT
Subject: RFR: 8354937: Cleanup some sparc related coding in os_linux
In-Reply-To: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
References: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
Message-ID: <nYZwgz0z0fCAW0h06sYDtp8u8Kdchrfo7g6wKgeMap4=.9b43f893-db3f-4119-9865-6879a1ccaec4@github.com>

On Wed, 5 Nov 2025 08:42:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is still some SPARC related coding remaining in os_linux, but we do not support Linux on SPARC for quite some time.
> 
> (there is more SPARC coding for detecting Sparc shared libs but I kept, that for now; not sure how important this is these days see https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L1762  )

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28143#pullrequestreview-3421913991

From stefank at openjdk.org  Wed Nov  5 13:55:26 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Nov 2025 13:55:26 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
Message-ID: <6okkjYqNRawvQ6BM8Oq5VVMTpfsE4LeMq31hIjjAh5s=.0ca7b626-40a2-456c-8636-086668c29651@github.com>

On Tue, 4 Nov 2025 11:56:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
>> 
>> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
>> 
>> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
>> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
>> 
>> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
>> 
>> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
>> 
>> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use String... as suggested by @stefank

OK. So, this misleading naming is already present in the OutputAnalyzer and this patch doesn't make things worse than what it already is.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3491341099

From stefank at openjdk.org  Wed Nov  5 13:58:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Nov 2025 13:58:37 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
Message-ID: <EZRSEpeaOmf7Un8IbzarszQpJz-92qUa31M-YRldfQ8=.3fe3184a-2be6-4ce8-a1a1-70b78d5df388@github.com>

On Tue, 4 Nov 2025 11:56:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
>> 
>> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
>> 
>> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
>> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
>> 
>> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
>> 
>> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
>> 
>> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use String... as suggested by @stefank

Marked as reviewed by stefank (Reviewer).

Looks good.

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

PR Review: https://git.openjdk.org/jdk/pull/28077#pullrequestreview-3422216751
PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3491355552

From lucy at openjdk.org  Wed Nov  5 14:01:03 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 5 Nov 2025 14:01:03 GMT
Subject: RFR: 8354937: Cleanup some sparc related coding in os_linux
In-Reply-To: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
References: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
Message-ID: <dIGu0H_NCe7pg42GbSP4LAcWAP3ptCWX6SOzMlW9vRA=.2a41467e-49ed-46d2-899e-85a1ca5f834c@github.com>

On Wed, 5 Nov 2025 08:42:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is still some SPARC related coding remaining in os_linux, but we do not support Linux on SPARC for quite some time.
> 
> (there is more SPARC coding for detecting Sparc shared libs but I kept, that for now; not sure how important this is these days see https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L1762  )

Looks good.

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

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28143#pullrequestreview-3422234863

From asmehra at openjdk.org  Wed Nov  5 14:08:59 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 14:08:59 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache [v2]
In-Reply-To: <Iq0gvwVzxObKh3GnZaPCGSQofBIxybMScdNs9TKTHpE=.86a4e6fd-ba47-49dc-a8f6-a380dc178e01@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <hISQ7zrsj2bxIqXy6bRSraeJwm2I4XQyZI8ZQL9Jkw8=.4fa23593-91b0-46c3-a5b5-4085076ef915@github.com>
 <Iq0gvwVzxObKh3GnZaPCGSQofBIxybMScdNs9TKTHpE=.86a4e6fd-ba47-49dc-a8f6-a380dc178e01@github.com>
Message-ID: <P0Zmeii4CjVRNtedPhcghDrJkl_z9rRzcyv3kKHMjk4=.208357c9-9ece-45ad-8647-0718643a76e2@github.com>

On Wed, 5 Nov 2025 09:19:51 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> Marked as reviewed by adinn (Reviewer).

@adinn thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28121#issuecomment-3491402694

From stefank at openjdk.org  Wed Nov  5 14:46:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 5 Nov 2025 14:46:54 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
Message-ID: <iRXfFqjf2iwzPIiSqGVsPpaljbSZ65nqrn5R2udX1Ks=.b6e8e8e7-4cf0-451e-8b63-625c5e6ff11e@github.com>

On Tue, 4 Nov 2025 19:07:32 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring to reduce code duplication

> I think the changes are minor to assert the tagging on allocation while we are doing that and do not require extra tests, please let me know if you still think otherwise.

I think otherwise. Please put the test somewhere else.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3422524897

From aboldtch at openjdk.org  Wed Nov  5 15:03:57 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 5 Nov 2025 15:03:57 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
Message-ID: <Jih2u7ZS3vtrXg31ea7_6tvvKQkoyW1Gc4vOu5ek7Bw=.2556609c-ef77-4f79-81be-6cc132ce1eda@github.com>

On Tue, 4 Nov 2025 19:07:32 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor refactoring to reduce code duplication

src/hotspot/os/bsd/os_bsd.hpp line 38:

> 36: // Shared constant for mmap file descriptor used across BSD OS implementations
> 37: static constexpr int bsd_mmap_fd =
> 38: #ifdef __APPLE__

Are these defines always available (present and future)? Or should they be guarded?
Suggestion:

#if defined(__APPLE__) && defined(VM_MAKE_TAG) && defined(VM_MEMORY_JAVA)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2494939644

From azafari at openjdk.org  Wed Nov  5 15:04:12 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 5 Nov 2025 15:04:12 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow
Message-ID: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>

In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.

The fix is to skip cases where page-number under checking is `-1`.
Tested under UBSAN build.

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

Commit messages:
 - 8361487: [ubsan] test_committed_virtualmemory.cpp check_covered_pages shows overflow

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

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

From iklam at openjdk.org  Wed Nov  5 16:12:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 5 Nov 2025 16:12:58 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code
In-Reply-To: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
Message-ID: <qmD8LhWfDTziLnQutckJn7EaMqety6NkdjxsGQkyn5o=.99f88c76-a151-4b0b-8704-37e482360981@github.com>

On Tue, 4 Nov 2025 19:08:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.

src/hotspot/share/cds/aotMetaspace.cpp line 2057:

> 2055:     CountSharedSymbols cl;
> 2056:     SymbolTable::shared_symbols_do(&cl);
> 2057:     tty->print_cr("Number of shared symbols: %ld", cl.total());

"%zu" should be used for size_t

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28139#discussion_r2495206343

From sgehwolf at openjdk.org  Wed Nov  5 18:30:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 5 Nov 2025 18:30:06 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping function
Message-ID: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>

Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.

For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):


f(x) = {(x - 2) \times 9999 + 1 \over 262142}


This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:


f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}


Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.

Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.

Thoughts?

**Testing:**
- [x] GHA
- [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

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

Commit messages:
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

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

From matsaave at openjdk.org  Wed Nov  5 19:33:00 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 5 Nov 2025 19:33:00 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code [v2]
In-Reply-To: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
Message-ID: <lW5Xr1TtHDYwE7gf6_iuTyhmeidFZLBw495RtzunyXA=.45cb18db-7774-4f85-a6c1-03449a57dc47@github.com>

> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:

 - Ioi comments
 - Changes more counters and sizes to size_t

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28139/files
  - new: https://git.openjdk.org/jdk/pull/28139/files/26b7b378..d7e054ff

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

  Stats: 32 lines in 7 files changed: 0 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/28139.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28139/head:pull/28139

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

From matsaave at openjdk.org  Wed Nov  5 19:33:02 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 5 Nov 2025 19:33:02 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code [v2]
In-Reply-To: <fMUFwCmnI2UHRCn25-Qi2a2cGSH-4-GSeeVbMeagVZc=.2b4bffcd-451b-4918-b5af-c5b2a4afa541@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
 <fMUFwCmnI2UHRCn25-Qi2a2cGSH-4-GSeeVbMeagVZc=.2b4bffcd-451b-4918-b5af-c5b2a4afa541@github.com>
Message-ID: <1xsO98bbon3l-7_Jj1VYO9SC-DI6S8jt65_EyMkq_Qw=.fc78611f-0c1f-44d8-b8f4-ada2e53efe10@github.com>

On Tue, 4 Nov 2025 20:18:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> You only changed `CountSharedSymbols::_count`. Please, adjust RFE's title accordingly.
> 
> I am not actually convinced why it is necessary. Can you explain why? What benefits you get with this change.

It's preferable to use size_t for counters so we can avoid having negative counts or overflows. I didn't notice any bugs aside from the one listed in the description but I think it is a good defense in depth strategy to use size_t when possible. The number of oops can potentially be very large so any fields that count oops should be size_t. Other areas in the VM use size_t to could classes as well even though it is unlikely to have more than 2 billion classes.

Additionally, some fields track size should also be size_t as these are values that cannot be negative and could possibly be quite large.

I found more instances of int to change to size_t and added them to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28139#issuecomment-3492953494

From kvn at openjdk.org  Wed Nov  5 19:47:09 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 5 Nov 2025 19:47:09 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code [v2]
In-Reply-To: <lW5Xr1TtHDYwE7gf6_iuTyhmeidFZLBw495RtzunyXA=.45cb18db-7774-4f85-a6c1-03449a57dc47@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
 <lW5Xr1TtHDYwE7gf6_iuTyhmeidFZLBw495RtzunyXA=.45cb18db-7774-4f85-a6c1-03449a57dc47@github.com>
Message-ID: <XcJA1hQFsgS1wV17CecYFRpOxh4A1j3uXGp4fZbgAKQ=.375451a3-4b86-47c5-b1cd-c8601d5fc172@github.com>

On Wed, 5 Nov 2025 19:33:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Ioi comments
>  - Changes more counters and sizes to size_t

Thank you for explanation and finding more cases - now the title is correct.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28139#pullrequestreview-3424016913

From iklam at openjdk.org  Wed Nov  5 20:35:02 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 5 Nov 2025 20:35:02 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code [v2]
In-Reply-To: <lW5Xr1TtHDYwE7gf6_iuTyhmeidFZLBw495RtzunyXA=.45cb18db-7774-4f85-a6c1-03449a57dc47@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
 <lW5Xr1TtHDYwE7gf6_iuTyhmeidFZLBw495RtzunyXA=.45cb18db-7774-4f85-a6c1-03449a57dc47@github.com>
Message-ID: <Cgm0BxWhmjq9eg1FjcUqRyIF2DRpsxsc9J3sIyoJEGA=.80041c2e-b342-4e72-9d85-fc308de762d1@github.com>

On Wed, 5 Nov 2025 19:33:00 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Ioi comments
>  - Changes more counters and sizes to size_t

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28139#pullrequestreview-3424232814

From iklam at openjdk.org  Wed Nov  5 20:49:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 5 Nov 2025 20:49:08 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache [v2]
In-Reply-To: <hISQ7zrsj2bxIqXy6bRSraeJwm2I4XQyZI8ZQL9Jkw8=.4fa23593-91b0-46c3-a5b5-4085076ef915@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <hISQ7zrsj2bxIqXy6bRSraeJwm2I4XQyZI8ZQL9Jkw8=.4fa23593-91b0-46c3-a5b5-4085076ef915@github.com>
Message-ID: <0V4nLmREvi-hEdGJ4PTE8r5Of0ZLv29YB2-3uMkTtOE=.0a76d668-e0b3-4136-be56-1a768cd5cfbd@github.com>

On Wed, 5 Nov 2025 01:33:39 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
>> 
>> Testing:
>> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64
>
> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments
>   
>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28121#pullrequestreview-3424311114

From asmehra at openjdk.org  Wed Nov  5 21:41:14 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 21:41:14 GMT
Subject: RFR: 8371178: Preserve fast version of getfield and putfield in
 AOTCache [v2]
In-Reply-To: <0V4nLmREvi-hEdGJ4PTE8r5Of0ZLv29YB2-3uMkTtOE=.0a76d668-e0b3-4136-be56-1a768cd5cfbd@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
 <hISQ7zrsj2bxIqXy6bRSraeJwm2I4XQyZI8ZQL9Jkw8=.4fa23593-91b0-46c3-a5b5-4085076ef915@github.com>
 <0V4nLmREvi-hEdGJ4PTE8r5Of0ZLv29YB2-3uMkTtOE=.0a76d668-e0b3-4136-be56-1a768cd5cfbd@github.com>
Message-ID: <SqsYVHDxDgQ3Jj4dotYGHMD98hKDzXLPprR3h0_IFFA=.9bf4a668-f491-4d67-8e53-8f4c10f86327@github.com>

On Wed, 5 Nov 2025 20:46:42 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> LGTM

@iklam thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28121#issuecomment-3493615433

From asmehra at openjdk.org  Wed Nov  5 21:41:15 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 21:41:15 GMT
Subject: Integrated: 8371178: Preserve fast version of getfield and putfield in
 AOTCache
In-Reply-To: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
References: <GKNqJwFGkVg9ejxJRgOqW1WmleUYzn_lVZ7R4-YDX_s=.3caf9551-097a-41ef-87ca-fa9d755ccd59@github.com>
Message-ID: <ajB9-17qp_8Z_XJZKbCq6kF81KkR1VnkL-8MYXzgVuY=.58d64b11-b0d6-4f3d-947e-feca03a28ba8@github.com>

On Tue, 4 Nov 2025 02:10:13 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

> Preserve the "fast" version of `getfield` and `putfield` bytecodes in the AOTCache during the assembly phase if the constant pool entry referred by the bytecodes is stored in resolved state in the AOTCache.
> 
> Testing:
> Testing with JTREG="AOT_JDK=true" TEST=hotspot_runtime_no_cds passed on x86-64

This pull request has now been integrated.

Changeset: 1357be98
Author:    Ashutosh Mehra <asmehra at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1357be98fc7aeb73655ed1a31d0b6fa7a7213c3e
Stats:     95 lines in 3 files changed: 83 ins; 0 del; 12 mod

8371178: Preserve fast version of getfield and putfield in AOTCache

Reviewed-by: adinn, iklam

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

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

From asmehra at openjdk.org  Wed Nov  5 22:58:01 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 5 Nov 2025 22:58:01 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address
In-Reply-To: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
Message-ID: <hAxa0KkLgtQeMNybVP8U-SVF3zMlkvv7ooINvgiHArw=.6b46060d-ac01-4505-b9c9-872385c8209d@github.com>

On Thu, 30 Oct 2025 05:46:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **Overview**
> 
> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
> 
> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
> 
> **The fix**
> 
> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
> 
> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
> 
> Please see comments in the above two functions for more details.

src/hotspot/share/cds/archiveHeapWriter.cpp line 96:

> 94:     guarantee(MIN_GC_REGION_ALIGNMENT <= G1HeapRegion::min_region_size_in_words() * HeapWordSize, "must be");
> 95: 
> 96:     if (CDSConfig::old_cds_flags_used() && !CDSConfig::is_dumping_aot_linked_classes() && UseG1GC) {

Wouldn't it be better to add a VM command line flag to indicate that deterministic dump is needed, and use that flag in `Images.gmk`, instead of relying on these conditions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28052#discussion_r2496449963

From iklam at openjdk.org  Thu Nov  6 04:51:15 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Nov 2025 04:51:15 GMT
Subject: RFR: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE [v4]
In-Reply-To: <EZRSEpeaOmf7Un8IbzarszQpJz-92qUa31M-YRldfQ8=.3fe3184a-2be6-4ce8-a1a1-70b78d5df388@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
 <8UxdVxjL8uyO-H1qTEZnkOJ7ZyJgHqCqqojcd-Ym2AU=.4cd10f65-a5dc-4f4f-a224-a8c305563272@github.com>
 <EZRSEpeaOmf7Un8IbzarszQpJz-92qUa31M-YRldfQ8=.3fe3184a-2be6-4ce8-a1a1-70b78d5df388@github.com>
Message-ID: <hZ7wJOCsrNAI86njK9She52xpX37XjT82litQqgoHtA=.fb0e6ca6-f691-4b4a-bc40-b7583e19859c@github.com>

On Wed, 5 Nov 2025 13:56:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use String... as suggested by @stefank
>
> Looks good.

Thanks @stefank for the review!
I tested tiers 1-5 and saw no regression, so it looks like the OutputAnalyzer changes work fine with existing tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/28077#issuecomment-3495030194

From iklam at openjdk.org  Thu Nov  6 04:51:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Nov 2025 04:51:16 GMT
Subject: Integrated: 8370975: OutputAnalyzer.matches() should use Matcher with
 Pattern.MULTILINE
In-Reply-To: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
References: <MBpFpxFsJyeZetiaNyHY02N_WyX96za7N16kJGXoEgo=.5eb09e74-d63f-4582-bab9-6b217a879a5a@github.com>
Message-ID: <qCWsSfNBB_P4GcBY4GAmHSHaoa4HYx2oUarbSAVDTJI=.dd2254d9-3636-4b75-9579-37f7868b9df4@github.com>

On Thu, 30 Oct 2025 22:53:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In the previous fix (https://github.com/openjdk/jdk/pull/28035), I added `OutputAnalyzer::match(String regexp)`, but it uses `String.matches()` which has different semantics than the existing "match" functions such as `OutputAnalyzer::shouldMatch()`. 
> 
> `String.matches()` is a poor choice for matching the stdout/stderr in `OutputAnalyzer`:
> 
> - It requires a full match, so you need to use `haystackString.matches(".*needle.*")`
> - But `.*` doesn't match across newlines, so it's basically useless for most program output.
> 
> That's why the pattern in the previous fix in AccessZeroNKlassHitsProtectionZone.java (https://github.com/openjdk/jdk/pull/28035)  doesn't work:
> 
> https://github.com/openjdk/jdk/blame/e4aed95cac343f1339b9bc87721561bdc4c2f5ad/test/hotspot/jtreg/runtime/ErrorHandling/AccessZeroNKlassHitsProtectionZone.java#L146
> 
> I fixed this by re-working `OutputAnalyzer::match()`, etc, to do the same thing as `OutputAnalyzer::shouldMatch()`.  I also refactored the code to consolidate most of the regexp handling code to the two `matchesHelper()` methods.

This pull request has now been integrated.

Changeset: 3f40f4c3
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f40f4c362f6ff4d1ec7d513b4690ed5fade3e2a
Stats:     111 lines in 2 files changed: 87 ins; 13 del; 11 mod

8370975: OutputAnalyzer.matches() should use Matcher with Pattern.MULTILINE

Reviewed-by: stefank

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

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

From mbaesken at openjdk.org  Thu Nov  6 08:30:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Nov 2025 08:30:15 GMT
Subject: RFR: 8354937: Cleanup some sparc related coding in os_linux
In-Reply-To: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
References: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
Message-ID: <Xph8bEjbrYmNh4tkJfQrfUnLoaE9Pk9Z_UV4eoSG_Ys=.da6097d0-c0d0-458f-898e-d5c7e9b6f666@github.com>

On Wed, 5 Nov 2025 08:42:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is still some SPARC related coding remaining in os_linux, but we do not support Linux on SPARC for quite some time.
> 
> (there is more SPARC coding for detecting Sparc shared libs but I kept, that for now; not sure how important this is these days see https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L1762  )

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/28143#issuecomment-3495820677

From mbaesken at openjdk.org  Thu Nov  6 08:30:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 6 Nov 2025 08:30:15 GMT
Subject: Integrated: 8354937: Cleanup some sparc related coding in os_linux
In-Reply-To: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
References: <FYgxV_WqgWX89WgY41aqtC2puE0xly8C9Rd5qs71FJU=.2b91a240-434d-4be5-9265-02020f97c4fa@github.com>
Message-ID: <UNCi-e4c_AVJFl0CvHDRFWiTPOb6_70VdQ9OwSwvaSI=.6367f75a-6e46-46e9-8d3f-298df53fd582@github.com>

On Wed, 5 Nov 2025 08:42:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is still some SPARC related coding remaining in os_linux, but we do not support Linux on SPARC for quite some time.
> 
> (there is more SPARC coding for detecting Sparc shared libs but I kept, that for now; not sure how important this is these days see https://github.com/openjdk/jdk/blob/master/src/hotspot/os/linux/os_linux.cpp#L1762  )

This pull request has now been integrated.

Changeset: 1b3889a4
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b3889a47092e018ab9ecb6aaa922046d8d0e916
Stats:     7 lines in 1 file changed: 0 ins; 6 del; 1 mod

8354937: Cleanup some sparc related coding in os_linux

Reviewed-by: ayang, mdoerr, lucy

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

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

From phubner at openjdk.org  Thu Nov  6 08:59:23 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 6 Nov 2025 08:59:23 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
Message-ID: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>

Hi all,

The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.

This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again

This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.

**Scenario 1: `CreateCoredumpOnCrash` is disabled**
> #
> # A fatal error has been detected by the Java Runtime Environment:
> # [...]
> # CreateCoredumpOnCrash turned off, no core file dumped

**Scenario 2: `get_core_path` errors**
> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core path is unknown, trying core.1552174 (may not exist)
> #
> # A fatal error has been detected by the Java Runtime Environment:
> # [...]
> # Core dump will be written. Default location: core.1552174 (may not exist)

**Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
> #
> # A fatal error has been detected by the Java Runtime Environment:
> # [...]
> # Core dump will be written. Default location: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/foo/bar/core.1555400)

**Scenario 4: the resource limit for core dumps could not be determined**
> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but couldn't deduce rlim, trying /tmp/cores/core.%e.1560382.%h.%t (may not exist)
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #  [...]
> # Core dump will be written. Default location: /tmp/cores/core.%e.1560382.%h.%t (may not exist)

**Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # A fatal error has been detected by the Java Runtime Environment:
> # [...]
> # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again

> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps are constrained (max size 1024 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> #
> # A fatal error has been detected by the Java Runtime Environment:
> # [...]
> # Core dump will be written. Default location: /tmp/cores/core.%e.1562878.%h.%t (max size 1024 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again

?? ^^^ this is the message reported to be misleading in the original issue.

> #
> # A fatal error has been detected by the Java Runtime Environment:
> # [...]
> # Core dump will be written. Default location: /tmp/cores/core.%e.1562952.%h.%t

Testing: tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

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

Commit messages:
 - Better posix coredump messages.

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

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

From matsaave at openjdk.org  Thu Nov  6 14:41:49 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 6 Nov 2025 14:41:49 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code [v3]
In-Reply-To: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
Message-ID: <kBA_GHZouqcH8v0Qz3S7zHiZvF6pv9HBC52S3vuxaMQ=.86f52029-7bb7-4db5-a10a-f0e61ff1e1ea@github.com>

> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.

Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:

  Windows fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28139/files
  - new: https://git.openjdk.org/jdk/pull/28139/files/d7e054ff..51febba1

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

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

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

From iklam at openjdk.org  Thu Nov  6 21:04:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 6 Nov 2025 21:04:03 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code [v3]
In-Reply-To: <kBA_GHZouqcH8v0Qz3S7zHiZvF6pv9HBC52S3vuxaMQ=.86f52029-7bb7-4db5-a10a-f0e61ff1e1ea@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
 <kBA_GHZouqcH8v0Qz3S7zHiZvF6pv9HBC52S3vuxaMQ=.86f52029-7bb7-4db5-a10a-f0e61ff1e1ea@github.com>
Message-ID: <yJXvL0TnNN3jlb5O8HobUbJVBhK1WwOFuLAFeNl9Q2E=.c33f4606-26b3-47c7-a8e5-e945b4921098@github.com>

On Thu, 6 Nov 2025 14:41:49 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

>> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.
>
> Matias Saavedra Silva has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Windows fix

Marked as reviewed by iklam (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28139#pullrequestreview-3430542523

From matsaave at openjdk.org  Thu Nov  6 21:04:06 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 6 Nov 2025 21:04:06 GMT
Subject: RFR: 8272160: Avoid using 32-bit counters in CDS code [v2]
In-Reply-To: <XcJA1hQFsgS1wV17CecYFRpOxh4A1j3uXGp4fZbgAKQ=.375451a3-4b86-47c5-b1cd-c8601d5fc172@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
 <lW5Xr1TtHDYwE7gf6_iuTyhmeidFZLBw495RtzunyXA=.45cb18db-7774-4f85-a6c1-03449a57dc47@github.com>
 <XcJA1hQFsgS1wV17CecYFRpOxh4A1j3uXGp4fZbgAKQ=.375451a3-4b86-47c5-b1cd-c8601d5fc172@github.com>
Message-ID: <nOVMcQkgxa11PUvFG-MXnExsKjI_nZZghHcbt0_sFeA=.7eb834d4-e659-4ad7-8597-27a96a970bd8@github.com>

On Wed, 5 Nov 2025 19:44:44 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Matias Saavedra Silva has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Ioi comments
>>  - Changes more counters and sizes to size_t
>
> Thank you for explanation and finding more cases - now the title is correct.

Thanks for the reviews @vnkozlov and @iklam!

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

PR Comment: https://git.openjdk.org/jdk/pull/28139#issuecomment-3499379259

From matsaave at openjdk.org  Thu Nov  6 21:07:12 2025
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Thu, 6 Nov 2025 21:07:12 GMT
Subject: Integrated: 8272160: Avoid using 32-bit counters in CDS code
In-Reply-To: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
References: <jlMICpQtk8ylUdTvWFtUkYuHx5svGEb3IdgtcNxd0Ck=.9ee7b6ae-e380-4987-a997-21e443e33787@github.com>
Message-ID: <uFSsLylrN65ErqBrGK-tw8VIh6Ligze5WyTsBqSS1kQ=.1c7ec520-8a98-4462-8f51-5c7095a82e65@github.com>

On Tue, 4 Nov 2025 19:08:34 GMT, Matias Saavedra Silva <matsaave at openjdk.org> wrote:

> There are a handful of counters in CDS code that are `int` when it would be safer to use size_t. While exploring this I discovered that the `_count` field in DumpTimeKlassSubGraphInfoTable is unused so it is removed and the one use case replaced with a more accurate value. Verified with tier1-5 tests.

This pull request has now been integrated.

Changeset: 87966112
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8796611206438c6fe8bf0cba87dca089d9da2e30
Stats:     40 lines in 7 files changed: 0 ins; 3 del; 37 mod

8272160: Avoid using 32-bit counters in CDS code

Reviewed-by: iklam, kvn

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

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

From duke at openjdk.org  Thu Nov  6 22:39:19 2025
From: duke at openjdk.org (duke)
Date: Thu, 6 Nov 2025 22:39:19 GMT
Subject: Withdrawn: 8366787: Test
 runtime/StackGuardPages/TestStackGuardPagesNative.java hangs on some platforms
In-Reply-To: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
References: <F6KZK7bQ1y7qCj6tYdNjDXQx03XWf6TOKYjFxIr_4ug=.a09757e4-37f5-4dbd-988c-379fa07efbec@github.com>
Message-ID: <-0RC8jQPgRTugK-gGaPgcAObXkrerMSuzjLRw5abO6o=.192932ab-7cc2-44b0-b910-27af1dee1e1f@github.com>

On Fri, 5 Sep 2025 09:51:58 GMT, mazhen <duke at openjdk.org> wrote:

> #### Summary
> 
> This PR fixes a hang in the `TestStackGuardPagesNative.java` test that occurs on certain Linux distributions (e.g., CentOS 7). The fix replaces an unbounded `for(;;)` loop in the native test code (`exeinvoke.c`) with a bounded `while` loop, making the test's behavior deterministic and robust across all platforms.
> 
> #### Problem
> 
> The test would hang and eventually time out on some platforms. This was caused by an unbounded `for(;;)` loop in the `do_overflow` function, which was introduced as part of the "hardening" fix in `JDK-8295344`.
> 
> *   On platforms like **CentOS 7**, this unbounded loop would not encounter a terminating signal in a timely manner, causing the native process to hang indefinitely until killed by the test harness.
> *   In contrast, on platforms like **Ubuntu 24**, the test would coincidentally pass because a `SEGV_MAPERR` would happen to terminate the loop. This highlighted that the test's success was reliant on platform-specific side effects, masking the underlying issue.
> 
> #### Solution
> 
> The solution is to replace the unbounded `for(;;)` loop with a bounded `while` loop. The condition `while (_kp_rec_count == 0 || _rec_count < _kp_rec_count)` ensures that the loop terminates deterministically after a specific number of allocations, corresponding to the overflow depth detected in the test's first phase.
> 
> This change makes the test's logic robust and its behavior consistent across different environments.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Nov  7 04:57:52 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 04:57:52 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v7]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <Xp6vG0ftFLCh0p9FDvrcjnN7EgRVa08rKIPwO7LN_jY=.6ba29e32-ff57-4a6b-95fb-b69cd2125272@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  consolidate unit tests for vm memory tagging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/183927b0..59f4722c

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

  Stats: 53 lines in 3 files changed: 20 ins; 32 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Fri Nov  7 04:57:53 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 04:57:53 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v6]
In-Reply-To: <iRXfFqjf2iwzPIiSqGVsPpaljbSZ65nqrn5R2udX1Ks=.b6e8e8e7-4cf0-451e-8b63-625c5e6ff11e@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <aNYlBTrMqX-L9LyoXOzKmqUPS2_iHLTWY8fEGhsxinA=.bd22087b-0f0a-43a0-81a8-a2f67c7449de@github.com>
 <iRXfFqjf2iwzPIiSqGVsPpaljbSZ65nqrn5R2udX1Ks=.b6e8e8e7-4cf0-451e-8b63-625c5e6ff11e@github.com>
Message-ID: <-_XVImRDDvjsMvf_7YNG_V-dFYfNqtdFC-xVrylQpPI=.8738f2f9-454e-4114-b7da-7c51667e580e@github.com>

On Wed, 5 Nov 2025 14:43:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > I think the changes are minor to assert the tagging on allocation while we are doing that and do not require extra tests, please let me know if you still think otherwise.
> 
> I think otherwise. Please put the test somewhere else.

Done

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

PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3500704669

From duke at openjdk.org  Fri Nov  7 05:02:22 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 05:02:22 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v8]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <t5LfL-ap58lMJ3_dL3W2xnMPyzL_UdrG2usSIjQZ6oM=.9330fa21-73b1-4c80-915b-e9ba89bf9ef7@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  remote testutils.hpp from test_zForwarding.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/59f4722c..0fbcdb09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=06-07

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

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

From jsjolen at openjdk.org  Fri Nov  7 05:02:23 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 7 Nov 2025 05:02:23 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v7]
In-Reply-To: <Xp6vG0ftFLCh0p9FDvrcjnN7EgRVa08rKIPwO7LN_jY=.6ba29e32-ff57-4a6b-95fb-b69cd2125272@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <Xp6vG0ftFLCh0p9FDvrcjnN7EgRVa08rKIPwO7LN_jY=.6ba29e32-ff57-4a6b-95fb-b69cd2125272@github.com>
Message-ID: <TD5EffrJG3_ocxkze9CkiRrS4daas0XzIv85dJ_no48=.0167c6c8-66e7-4249-83ca-e4376d88f6dd@github.com>

On Fri, 7 Nov 2025 04:57:52 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   consolidate unit tests for vm memory tagging

Changes requested by jsjolen (Reviewer).

test/hotspot/gtest/runtime/test_os.cpp line 1133:

> 1131:   char* base = os::reserve_memory(size, mtTest, false);
> 1132:   ASSERT_NOT_NULL(base);
> 1133: 

Remove this change

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

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3431645714
PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2501685500

From duke at openjdk.org  Fri Nov  7 05:08:20 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 05:08:20 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v9]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <sN6A_77iG1YR6_RuDHNWQ4t3Ftwr8hKY_hNBAmyNM4M=.358df287-e93e-4548-ba64-f208820ea0be@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  remove blanck line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/0fbcdb09..d8d09007

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=07-08

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

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

From duke at openjdk.org  Fri Nov  7 05:22:10 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 7 Nov 2025 05:22:10 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v9]
In-Reply-To: <2yddz-oh3R_8sZlR6zagp-aoev24wvWTGw_7yFCL1yo=.9ad83098-76c8-41d5-9645-63335cb0b2a2@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <2yddz-oh3R_8sZlR6zagp-aoev24wvWTGw_7yFCL1yo=.9ad83098-76c8-41d5-9645-63335cb0b2a2@github.com>
Message-ID: <mFshQWvE96ZhWqV915bEzfYqvr7mQkfqjcvoJnr8g-w=.f71fcdda-c6bc-4f8c-9f77-9a3a60bf2cb4@github.com>

On Wed, 29 Oct 2025 17:41:35 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> The PR needs gtest/jtreg testing results. Also it needs to be checks the new code is covered by existing gtests or new tests are needed.

Done

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

PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3500768402

From azafari at openjdk.org  Fri Nov  7 08:40:02 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 08:40:02 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v16]
In-Reply-To: <fFD5QFu8N2bMfc1JVDm4Xx2hG3RCjMsxE3gTkm1heQQ=.0d37ce54-62a5-4b5d-a464-db2f29432293@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <DWvXEJ1vmq4z76zONCHQ2l6chiAK2B86GeqgkScQSAU=.1e7cb038-ecd0-420a-b814-ab268b0fde26@github.com>
 <fFD5QFu8N2bMfc1JVDm4Xx2hG3RCjMsxE3gTkm1heQQ=.0d37ce54-62a5-4b5d-a464-db2f29432293@github.com>
Message-ID: <45uPTVWlSrlpGb6ksIlGUF9NrRwC3ZSUX06XF8zHPYA=.e9b93931-8f10-47a0-af09-9c0bd8c12751@github.com>

On Wed, 5 Nov 2025 09:17:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed problem after merge
>
> src/hotspot/share/nmt/mallocHeader.hpp line 91:
> 
>> 89:  */
>> 90: 
>> 91: 
> 
> Remove

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2502145285

From azafari at openjdk.org  Fri Nov  7 08:40:03 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 08:40:03 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v7]
In-Reply-To: <os-FO6DCeGitoJOKbbnAB8FyfUc5DUGzPr1qjvSx3B8=.9ad54f36-306e-4a5d-b2b8-f521b3eb6942@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <uPUI0iuNOtY_mMUDAB4ZHVHYgitiA3eIRawjuqpMcsY=.ab7f61d6-e33e-4312-af25-b643ae670e1b@github.com>
 <czi20gtqU5KWXpQJyvAXYkkmIk_2ZeGx8Iqltnd3Ih8=.35ca01b5-683c-4d26-a5bb-6f9b70b04a19@github.com>
 <o9n13ffy9-zfhaJ5GUAd6R5l483XPWdj9JSFOBUeoSg=.64b823ae-5a8b-40f9-8fa3-c780bc913042@github.com>
 <os-FO6DCeGitoJOKbbnAB8FyfUc5DUGzPr1qjvSx3B8=.9ad54f36-306e-4a5d-b2b8-f521b3eb6942@github.com>
Message-ID: <eYt_BXUNE9EEUggfOQU3pHL_KS0IHyAv6gpG81WUp34=.f37c44af-747c-4bdc-b362-af81bcb9819c@github.com>

On Wed, 5 Nov 2025 09:22:32 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> In `.../clang/15.0.0/include/sanitizer/asan_interface.h`, the ASAN_(UN)POISON_MEMORY_REGION  macros would be empty as  
>> ```C++
>> // Macros provided for convenience.
>> #if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__)
>> /// Marks a memory region as unaddressable.
>> ///
>> /// \note Macro provided for convenience; defined as a no-op if ASan is not
>> /// enabled.
>> ///
>> /// \param addr Start of memory region.
>> /// \param size Size of memory region.
>> #define ASAN_POISON_MEMORY_REGION(addr, size) \
>>   __asan_poison_memory_region((addr), (size))
>> 
>> /// Marks a memory region as addressable.
>> ///
>> /// \note Macro provided for convenience; defined as a no-op if ASan is not
>> /// enabled.
>> ///
>> /// \param addr Start of memory region.
>> /// \param size Size of memory region.
>> #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \
>>   __asan_unpoison_memory_region((addr), (size))
>> #else
>> #define ASAN_POISON_MEMORY_REGION(addr, size) \
>>   ((void)(addr), (void)(size))
>> #define ASAN_UNPOISON_MEMORY_REGION(addr, size) \
>>   ((void)(addr), (void)(size))
>> #endif
>> 
>> 
>> I couldn't find yet why is that. So a fast/certain solution was to define the `__SANITIZE_ADDRESS__` explicitly.
>> Should be found before integrating this PR.
>
> @afshin-zafari , could you respond to this?

It was not needed. Removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2502139513

From azafari at openjdk.org  Fri Nov  7 08:53:23 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 08:53:23 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v17]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <M8QRxO-ermCHnU2y8728gtEOKC99YvGgqLYOum_w0Ik=.5911d663-98df-4fc7-840c-710ede338761@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  review comments applied.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27685/files
  - new: https://git.openjdk.org/jdk/pull/27685/files/8baffef9..e80c3c51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=15-16

  Stats: 27 lines in 2 files changed: 13 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685

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

From azafari at openjdk.org  Fri Nov  7 08:53:24 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 08:53:24 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v7]
In-Reply-To: <EANJGn9gqJ4IrHmjOObOxzODPFv3l9hiERotDCSG-oA=.567ba5b6-1f87-4698-804a-24c19e18b5dd@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <uPUI0iuNOtY_mMUDAB4ZHVHYgitiA3eIRawjuqpMcsY=.ab7f61d6-e33e-4312-af25-b643ae670e1b@github.com>
 <bPVRXHRXhmF5FMgLgIvBUPtYKvyp1qQdK093ED4bRFc=.133abfa9-638e-467d-9978-85bfa9d25a6a@github.com>
 <j3r2esCNXqXK4iAU1VcnBfXKKvpyYYBXdcA3lLj1iYg=.11d5cc7b-7655-4983-807e-fa2483bfc508@github.com>
 <EANJGn9gqJ4IrHmjOObOxzODPFv3l9hiERotDCSG-oA=.567ba5b6-1f87-4698-804a-24c19e18b5dd@github.com>
Message-ID: <N7SPda0tm6Ezd9hhRBdB0ZcgeAW-Li7Qwq-mDZa-XlQ=.595a8dc3-1776-4ebd-8cdf-92c76cfe8540@github.com>

On Wed, 15 Oct 2025 07:43:40 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Kept. to be used in gtests.
>
> See comment about the `using` statements.

Done.

>> return values removed.
>
> Then we're doing a lot of special code in the implementation only for the purpose of testing. That's going to be quite surprising for the next reader. If anything, we *should* use these typedefs in the implementation.

Fixed by other changes in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2502172599
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2502171904

From azafari at openjdk.org  Fri Nov  7 08:53:27 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 08:53:27 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v16]
In-Reply-To: <fFD5QFu8N2bMfc1JVDm4Xx2hG3RCjMsxE3gTkm1heQQ=.0d37ce54-62a5-4b5d-a464-db2f29432293@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <DWvXEJ1vmq4z76zONCHQ2l6chiAK2B86GeqgkScQSAU=.1e7cb038-ecd0-420a-b814-ab268b0fde26@github.com>
 <fFD5QFu8N2bMfc1JVDm4Xx2hG3RCjMsxE3gTkm1heQQ=.0d37ce54-62a5-4b5d-a464-db2f29432293@github.com>
Message-ID: <MK-U2bAlN9nBu6FDlkKyOyuEEsytOyEQ0sliGG3mihw=.c73277da-6006-4271-8660-22ead82a0c41@github.com>

On Wed, 5 Nov 2025 09:21:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed problem after merge
>
> src/hotspot/share/nmt/mallocHeader.hpp line 155:
> 
>> 153: 
>> 154:   uint8_t* footer_address() const { return ((address)this) + sizeof(MallocHeader) + size(); }
>> 155: 
> 
> Why is this moved to the public interface? If it's for the tests, then use a fixture class and a `friend class` declaration in `MallocHeader`.

No need. Moved to private.

> src/hotspot/share/nmt/mallocHeader.hpp line 189:
> 
>> 187:     AsanPoisoningHelper aph(&_canary);
>> 188:     return _canary;
>> 189:   }
> 
> Why is this moved to the public interface?

No reason to be public. Moved to private.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2502180493
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2502179380

From phubner at openjdk.org  Fri Nov  7 08:54:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 7 Nov 2025 08:54:50 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails
 with unexpected amount for Java Heap reserved memory
Message-ID: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>

Hi all,

In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.

It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
a) to ensure that some sort of reservation size is reported; and
b) to extract the reserved amount and assert that it is no less than the committed amount

Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).

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

Commit messages:
 - Use regular expression based matching instead.

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

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

From mbaesken at openjdk.org  Fri Nov  7 09:14:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Nov 2025 09:14:11 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
Message-ID: <lVp84wjrHokKjOPEmfGpn2IME4Bo4ytiDd89y3zS3go=.07120b5a-6f2e-46cc-98ba-8496ddfe7970@github.com>

On Thu, 6 Nov 2025 16:36:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> It turns out that, rarely, we do reserve more memory even without asan enabled.

We only saw this with ASAN and there was an explanation why this happened.
Any idea  why did this occur in your tests, without ASAN ? 

(otherwise the test looks okay if we really agree that this check should be relaxed)

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

PR Comment: https://git.openjdk.org/jdk/pull/28179#issuecomment-3501414381

From azafari at openjdk.org  Fri Nov  7 09:28:51 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 09:28:51 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v18]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <U2p4dsGBEle370ZH6tfrWAAgZQRHICiaURKqJgEbGEo=.adba7179-cb01-418c-8d70-9f9f0c38e933@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer
 - review comments applied.
 - fixed problem after merge
 - Merge remote-tracking branch 'jdksjolen/test-canary' into _20251006_asan_hdr_footer
 - A different way
 - NOT_LP64 fixes
 - AHP -> sanitizers/address.hpp
 - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer
 - include order
 - clean ups
 - ... and 13 more: https://git.openjdk.org/jdk/compare/866faa9d...f9a0db5f

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

Changes: https://git.openjdk.org/jdk/pull/27685/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=17
  Stats: 266 lines in 5 files changed: 225 ins; 5 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/27685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685

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

From azafari at openjdk.org  Fri Nov  7 10:06:46 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 10:06:46 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v19]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <5oyMa-ZTTl_F0wl2TH5VxHgxgjXxZehApKW99jbAwJE=.44d2fcd8-72c3-4c9f-a041-c9c9546d7ffb@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  fixes after merge.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27685/files
  - new: https://git.openjdk.org/jdk/pull/27685/files/f9a0db5f..bacd891e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=17-18

  Stats: 31 lines in 2 files changed: 10 ins; 17 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685

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

From azafari at openjdk.org  Fri Nov  7 11:14:13 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 11:14:13 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
Message-ID: <WSY1t_RTCktgXDXCTdQMTfSFT5ZrJVdom0sCN9jCt-k=.8b787d9f-387e-46ff-b453-e3fe2b24c755@github.com>

On Thu, 6 Nov 2025 16:36:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
> 
> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
> a) to ensure that some sort of reservation size is reported; and
> b) to extract the reserved amount and assert that it is no less than the committed amount
> 
> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).

Thank you @Arraying for taking this.
The condition of `reserved < committed` is/should be always true, otherwise NMT is not doing its tasks correctly.
I suggest to check if the reported amount of `reserved` (and `committed` for a restricter condition) is at least 64M (which is given as options in command line).

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

PR Review: https://git.openjdk.org/jdk/pull/28179#pullrequestreview-3433132003

From phubner at openjdk.org  Fri Nov  7 11:18:00 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 7 Nov 2025 11:18:00 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <lVp84wjrHokKjOPEmfGpn2IME4Bo4ytiDd89y3zS3go=.07120b5a-6f2e-46cc-98ba-8496ddfe7970@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
 <lVp84wjrHokKjOPEmfGpn2IME4Bo4ytiDd89y3zS3go=.07120b5a-6f2e-46cc-98ba-8496ddfe7970@github.com>
Message-ID: <INnAXzevaH1Nus8GoNaHRqwkdL_jLLvCOsDiovU3Xdw=.dc0e28d6-17af-4ba1-9f91-7a97b0c152e9@github.com>

On Fri, 7 Nov 2025 09:11:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > It turns out that, rarely, we do reserve more memory even without asan enabled.
> 
> We only saw this with ASAN and there was an explanation why this happened. Any idea why did this occur in your tests, without ASAN ?
> 
> (otherwise the test looks okay if we really agree that this check should be relaxed)

@jsikstro and I are doing a small investigation into this, I'll keep you updated. We see that G1's reservation size is what we expect, but CDS also uses the `mtJavaHeap` tag.


> The condition of `reserved < committed` is/should be always true, otherwise NMT is not doing its tasks correctly.
> I suggest to check if the reported amount of `reserved` (and `committed` for a restricter condition) is at least 64M (which is given as options in command line).

Would it make sense to keep `reserved < committed` as a sanity check? Would you also suggest checking that `|reserved - committed| <= some_upper_bound`?

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

PR Comment: https://git.openjdk.org/jdk/pull/28179#issuecomment-3501945001

From azafari at openjdk.org  Fri Nov  7 11:23:01 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 7 Nov 2025 11:23:01 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <INnAXzevaH1Nus8GoNaHRqwkdL_jLLvCOsDiovU3Xdw=.dc0e28d6-17af-4ba1-9f91-7a97b0c152e9@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
 <lVp84wjrHokKjOPEmfGpn2IME4Bo4ytiDd89y3zS3go=.07120b5a-6f2e-46cc-98ba-8496ddfe7970@github.com>
 <INnAXzevaH1Nus8GoNaHRqwkdL_jLLvCOsDiovU3Xdw=.dc0e28d6-17af-4ba1-9f91-7a97b0c152e9@github.com>
Message-ID: <-2fpXUl9lcP7tXUf1FgW28vp01L08FLZd7hdvGjqSWw=.01c4258b-5046-4a9c-aabc-a3151008102d@github.com>

On Fri, 7 Nov 2025 11:15:11 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Would it make sense to keep `reserved < committed` as a sanity check? Would you also suggest checking that `|reserved - committed| <= some_upper_bound`?

Sorry my mistake, `reserved >= committed` should be always true.
For this specific test we only know that the amount has to be 64M. There is no general/global `some_upper_bound`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28179#issuecomment-3501967407

From sgehwolf at openjdk.org  Fri Nov  7 15:28:01 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 7 Nov 2025 15:28:01 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/2866c0a7..464d162f

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

  Stats: 17030 lines in 439 files changed: 10578 ins; 4853 del; 1599 mod
  Patch: https://git.openjdk.org/jdk/pull/28157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28157/head:pull/28157

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

From phh at openjdk.org  Fri Nov  7 22:13:07 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 7 Nov 2025 22:13:07 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v9]
In-Reply-To: <sN6A_77iG1YR6_RuDHNWQ4t3Ftwr8hKY_hNBAmyNM4M=.358df287-e93e-4548-ba64-f208820ea0be@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <sN6A_77iG1YR6_RuDHNWQ4t3Ftwr8hKY_hNBAmyNM4M=.358df287-e93e-4548-ba64-f208820ea0be@github.com>
Message-ID: <qgSM94Nx_Fbj-zPzvZslyQlwmurFZ-UfEUT_8LUAhhc=.9faa0bea-1c4c-4a5f-9d03-7efbae1c316f@github.com>

On Fri, 7 Nov 2025 05:08:20 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove blanck line

Changes requested by phh (Reviewer).

src/hotspot/os/bsd/os_bsd.cpp line 107:

> 105:   #include <mach/task_info.h>
> 106:   #include <mach-o/dyld.h>
> 107:   #include <mach/vm_statistics.h>

You don't need this here because you included it in os_bsd.hpp.

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

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3436641793
PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2505700791

From duke at openjdk.org  Sat Nov  8 00:05:38 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Sat, 8 Nov 2025 00:05:38 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v10]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <N4pE0RzjCb8qwt2Tfjsx8WmfpfSA9zeMylRp5rz9pGs=.48775561-bbd3-44af-8561-7e35075b8031@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  remove unncessary included

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/d8d09007..83f63ce5

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

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

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

From duke at openjdk.org  Sat Nov  8 00:05:40 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Sat, 8 Nov 2025 00:05:40 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls [v9]
In-Reply-To: <qgSM94Nx_Fbj-zPzvZslyQlwmurFZ-UfEUT_8LUAhhc=.9faa0bea-1c4c-4a5f-9d03-7efbae1c316f@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <sN6A_77iG1YR6_RuDHNWQ4t3Ftwr8hKY_hNBAmyNM4M=.358df287-e93e-4548-ba64-f208820ea0be@github.com>
 <qgSM94Nx_Fbj-zPzvZslyQlwmurFZ-UfEUT_8LUAhhc=.9faa0bea-1c4c-4a5f-9d03-7efbae1c316f@github.com>
Message-ID: <TEpqn4mAX-eputcs8dvL1KjH_P17o8PrOCaREhlkdgA=.88553c3b-3c05-46db-bcd9-52a7f4f65267@github.com>

On Fri, 7 Nov 2025 22:09:40 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove blanck line
>
> src/hotspot/os/bsd/os_bsd.cpp line 107:
> 
>> 105:   #include <mach/task_info.h>
>> 106:   #include <mach-o/dyld.h>
>> 107:   #include <mach/vm_statistics.h>
> 
> You don't need this here because you included it in os_bsd.hpp.

Yes, fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2505882636

From syan at openjdk.org  Sat Nov  8 08:17:39 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 8 Nov 2025 08:17:39 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
Message-ID: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>

Hi all,

The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.

This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.

Change has been verified locally on linux-x64 by run the all touched tests.

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

Commit messages:
 - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests

Changes: https://git.openjdk.org/jdk/pull/28208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371503
  Stats: 39 lines in 11 files changed: 2 ins; 20 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208

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

From swen at openjdk.org  Mon Nov 10 00:46:29 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 10 Nov 2025 00:46:29 GMT
Subject: RFR: 8371431: Warning message when turning off CompactStrings
Message-ID: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>

A warning message should be given before removing the CompactStrings off option.

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

Commit messages:
 - Merge branch 'master' into compact_str_warn_2510
 - from @liach
 - add warnings

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

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

From liach at openjdk.org  Mon Nov 10 00:46:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 10 Nov 2025 00:46:29 GMT
Subject: RFR: 8371431: Warning message when turning off CompactStrings
In-Reply-To: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
References: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
Message-ID: <BO7-4vmyh8AJ_6NRzFdjriEuNeXLYXDkPFOxFRHf-Zc=.3167268d-9ecf-49d0-aad8-709fd6e06944@github.com>

On Mon, 27 Oct 2025 01:26:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A warning message should be given before removing the CompactStrings off option.

I think the code change looks like:

diff --git a/src/hotspot/cpu/arm/globals_arm.hpp b/src/hotspot/cpu/arm/globals_arm.hpp
index 363a9a2c25c..d64615dd142 100644
--- a/src/hotspot/cpu/arm/globals_arm.hpp
+++ b/src/hotspot/cpu/arm/globals_arm.hpp
@@ -69,7 +69,7 @@ define_pd_global(bool,  PreserveFramePointer,     false);
 define_pd_global(uintx, TypeProfileLevel, 0);
 
 // No performance work done here yet.
-define_pd_global(bool, CompactStrings, false);
+define_pd_global(bool, CompactStrings, true);
 
 define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong);
 
diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
index 0d92f22af79..ac9eb7b6932 100644
--- a/src/hotspot/share/runtime/arguments.cpp
+++ b/src/hotspot/share/runtime/arguments.cpp
@@ -541,6 +541,7 @@ static SpecialFlag const special_jvm_flags[] = {
 
   // -------------- Obsolete Flags - sorted by expired_in --------------
 
+  { "CompactStrings",                JDK_Version::jdk(25),  JDK_Version::jdk(27), JDK_Version::jdk(28) },
 #ifdef LINUX
   { "UseOprofile",                  JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) },
 #endif


And backport the arguments.cpp but not globals_arm back to 25 updates.

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

PR Comment: https://git.openjdk.org/jdk/pull/27995#issuecomment-3453150014

From dholmes at openjdk.org  Mon Nov 10 00:46:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 10 Nov 2025 00:46:29 GMT
Subject: RFR: 8371431: Warning message when turning off CompactStrings
In-Reply-To: <BO7-4vmyh8AJ_6NRzFdjriEuNeXLYXDkPFOxFRHf-Zc=.3167268d-9ecf-49d0-aad8-709fd6e06944@github.com>
References: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
 <BO7-4vmyh8AJ_6NRzFdjriEuNeXLYXDkPFOxFRHf-Zc=.3167268d-9ecf-49d0-aad8-709fd6e06944@github.com>
Message-ID: <0Pyo3XIHelfYv00yWKxmqUPxwxJTYJkh2G2lZYqVNB8=.b66e01b5-cfb5-4b55-8d53-657fc63137b8@github.com>

On Mon, 27 Oct 2025 20:21:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A warning message should be given before removing the CompactStrings off option.
>
> I think the code change looks like:
> 
> diff --git a/src/hotspot/cpu/arm/globals_arm.hpp b/src/hotspot/cpu/arm/globals_arm.hpp
> index 363a9a2c25c..d64615dd142 100644
> --- a/src/hotspot/cpu/arm/globals_arm.hpp
> +++ b/src/hotspot/cpu/arm/globals_arm.hpp
> @@ -69,7 +69,7 @@ define_pd_global(bool,  PreserveFramePointer,     false);
>  define_pd_global(uintx, TypeProfileLevel, 0);
>  
>  // No performance work done here yet.
> -define_pd_global(bool, CompactStrings, false);
> +define_pd_global(bool, CompactStrings, true);
>  
>  define_pd_global(intx, InitArrayShortSize, 8*BytesPerLong);
>  
> diff --git a/src/hotspot/share/runtime/arguments.cpp b/src/hotspot/share/runtime/arguments.cpp
> index 0d92f22af79..ac9eb7b6932 100644
> --- a/src/hotspot/share/runtime/arguments.cpp
> +++ b/src/hotspot/share/runtime/arguments.cpp
> @@ -541,6 +541,7 @@ static SpecialFlag const special_jvm_flags[] = {
>  
>    // -------------- Obsolete Flags - sorted by expired_in --------------
>  
> +  { "CompactStrings",                JDK_Version::jdk(25),  JDK_Version::jdk(27), JDK_Version::jdk(28) },
>  #ifdef LINUX
>    { "UseOprofile",                  JDK_Version::jdk(25), JDK_Version::jdk(26), JDK_Version::jdk(27) },
>  #endif
> 
> 
> And backport the arguments.cpp but not globals_arm back to 25 updates.

@liach we can't just enable CS for ARM-32-bit. Unclear if it even works if you try to do that, but there are no C2 intrinsics related to CS so performance could take quite a hit.

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

PR Comment: https://git.openjdk.org/jdk/pull/27995#issuecomment-3465595986

From aboldtch at openjdk.org  Mon Nov 10 06:19:11 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 10 Nov 2025 06:19:11 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v10]
In-Reply-To: <N4pE0RzjCb8qwt2Tfjsx8WmfpfSA9zeMylRp5rz9pGs=.48775561-bbd3-44af-8561-7e35075b8031@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <N4pE0RzjCb8qwt2Tfjsx8WmfpfSA9zeMylRp5rz9pGs=.48775561-bbd3-44af-8561-7e35075b8031@github.com>
Message-ID: <XI5rjgw5lRoRmmAXmyQAqCvSEutq0WaRDCivDk755p0=.22e3a6b8-2ee7-42bb-bba8-8a3fe26f8501@github.com>

On Sat, 8 Nov 2025 00:05:38 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unncessary included

src/hotspot/os/bsd/os_bsd.hpp line 38:

> 36: // Shared constant for mmap file descriptor used across BSD OS implementations
> 37: static constexpr int bsd_mmap_fd =
> 38: #if defined(__APPLE__) && defined(VM_MAKE_TAG) && defined(VM_MEMORY_JAVA)

This did create some asymmetry now where this and the test is guarded, but the test utility which also requires `VM_MEMORY_JAVA` to be defined is not.

I might be better to use this condition once in this header file and introduce a new define which we use as the condition for the tagged memory related code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2508888148

From syan at openjdk.org  Mon Nov 10 06:24:07 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:24:07 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
Message-ID: <HdeaUOSonudRRksAEEq9KmIMVMywA5lCi3LgEw__aHg=.1d680a89-f49a-43aa-bb84-8980cdab0603@github.com>

On Fri, 7 Nov 2025 15:28:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

test/hotspot/jtreg/containers/docker/TestMisc.java line 43:

> 41: import jdk.test.lib.process.OutputAnalyzer;
> 42: import jdk.test.lib.process.ProcessTools;
> 43: import jtreg.SkippedException;

Does this import 'import jtreg.SkippedException;' really needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2508898251

From syan at openjdk.org  Mon Nov 10 06:43:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 06:43:03 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
Message-ID: <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>

On Fri, 7 Nov 2025 15:28:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `y=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

Before apply the propose patch, test jdk/internal/platform/docker/TestDockerCpuMetrics.java run failed. After apply the propose patch, test jdk/internal/platform/docker/TestDockerCpuMetrics.java run passed.

test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:

> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
> 150:             // value.
> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +

I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3441113583
PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2508932192

From alanb at openjdk.org  Mon Nov 10 07:13:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 10 Nov 2025 07:13:02 GMT
Subject: RFR: 8371431: Warning message when turning off CompactStrings
In-Reply-To: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
References: <N2eKy-Mvph7nC71NSY3OchmQHhQ4GU-T1esSNLmDauY=.9e2347d8-bedd-4d4f-b000-791c9cdf8c24@github.com>
Message-ID: <weeO8hmWRYszulDr7T6vA5lRgjR2bjK4vVo8UqK61l0=.ddc84977-28e0-4566-b958-90305f75c038@github.com>

On Mon, 27 Oct 2025 01:26:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A warning message should be given before removing the CompactStrings off option.

There is discussion on core-libs-dev about creating a JEP to document the story in a way that gets to the far reaches of the galaxy where -XX:-CompactStrings might be used.

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

PR Comment: https://git.openjdk.org/jdk/pull/27995#issuecomment-3509778753

From jsjolen at openjdk.org  Mon Nov 10 08:24:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Nov 2025 08:24:07 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v19]
In-Reply-To: <5oyMa-ZTTl_F0wl2TH5VxHgxgjXxZehApKW99jbAwJE=.44d2fcd8-72c3-4c9f-a041-c9c9546d7ffb@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <5oyMa-ZTTl_F0wl2TH5VxHgxgjXxZehApKW99jbAwJE=.44d2fcd8-72c3-4c9f-a041-c9c9546d7ffb@github.com>
Message-ID: <Eb43ccrrDBrbMStN8f6rmfjg6Cg5KURPLObtxFgXJrI=.3de56583-2d76-449d-89d9-dbc10d35dba1@github.com>

On Fri, 7 Nov 2025 10:06:46 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixes after merge.

Marked as reviewed by jsjolen (Reviewer).

test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 33:

> 31: #include "utilities/ostream.hpp"
> 32: #include "unittest.hpp"
> 33: #include "testutils.hpp"

I think our style dictates that this change should be reverted.

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

PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3441497591
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2509233975

From azafari at openjdk.org  Mon Nov 10 08:46:41 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 10 Nov 2025 08:46:41 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  order of includes corrected.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27685/files
  - new: https://git.openjdk.org/jdk/pull/27685/files/bacd891e..626fc490

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=18-19

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

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

From jsjolen at openjdk.org  Mon Nov 10 09:05:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Nov 2025 09:05:09 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
Message-ID: <tfo6CzIm61dneqYPXVQqClS6O8mkTFch-4om6L1SS0M=.01db2c12-4d81-4f7d-8810-c4fb3bf612c0@github.com>

On Mon, 10 Nov 2025 08:46:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order of includes corrected.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3441756471

From sgehwolf at openjdk.org  Mon Nov 10 09:25:05 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 09:25:05 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
Message-ID: <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>

On Mon, 10 Nov 2025 06:38:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Fix include
>>  - Add asserts/checks for input domain
>>  - Add regression test for jdk-8370492
>>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function
>
> test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:
> 
>> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
>> 150:             // value.
>> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +
> 
> I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'

I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509490319

From azafari at openjdk.org  Mon Nov 10 09:36:08 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 10 Nov 2025 09:36:08 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v18]
In-Reply-To: <Eb43ccrrDBrbMStN8f6rmfjg6Cg5KURPLObtxFgXJrI=.3de56583-2d76-449d-89d9-dbc10d35dba1@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <5oyMa-ZTTl_F0wl2TH5VxHgxgjXxZehApKW99jbAwJE=.44d2fcd8-72c3-4c9f-a041-c9c9546d7ffb@github.com>
 <Eb43ccrrDBrbMStN8f6rmfjg6Cg5KURPLObtxFgXJrI=.3de56583-2d76-449d-89d9-dbc10d35dba1@github.com>
Message-ID: <iKi0BkrC2SCh5RFTidmy7xchKcblgxbhNdgyBXuQSzg=.7cf7c9e2-70b3-4c06-9a7b-8309eb90f206@github.com>

On Mon, 10 Nov 2025 08:20:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer
>>  - review comments applied.
>>  - fixed problem after merge
>>  - Merge remote-tracking branch 'jdksjolen/test-canary' into _20251006_asan_hdr_footer
>>  - A different way
>>  - NOT_LP64 fixes
>>  - AHP -> sanitizers/address.hpp
>>  - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer
>>  - include order
>>  - clean ups
>>  - ... and 13 more: https://git.openjdk.org/jdk/compare/866faa9d...f9a0db5f
>
> test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 33:
> 
>> 31: #include "unittest.hpp"
>> 32: #include "utilities/debug.hpp"
>> 33: #include "utilities/ostream.hpp"
> 
> I think our style dictates that this change should be reverted.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2509547789

From syan at openjdk.org  Mon Nov 10 09:41:03 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 10 Nov 2025 09:41:03 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
 <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
Message-ID: <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>

On Mon, 10 Nov 2025 09:22:01 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jdk/jdk/internal/platform/docker/MetricsCpuTester.java line 151:
>> 
>>> 149:             // have a 1-to-1 mapping from the cgroup v2 value to the OCI
>>> 150:             // value.
>>> 151:             System.out.println("Debug: cgv2 - Got CPU shares of: " +
>> 
>> I found you 'import jtreg.SkippedException;' on file test/hotspot/jtreg/containers/docker/TestMisc.java. Do you want to 'throw new SkippedException' rather that just print 'Skipping assert'
>
> I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?

So does the 'import jtreg.SkippedException;' in file test/hotspot/jtreg/containers/docker/TestMisc.java seems do not needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509574859

From sgehwolf at openjdk.org  Mon Nov 10 10:22:07 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 10:22:07 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v2]
In-Reply-To: <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <wzZWJZ_F7dCFpWUgrS4VmPTv5xw4VZ7cTbc4w_X_1Z4=.f8180414-19a6-4041-8b6f-dbe690e31e15@github.com>
 <pek9EB_3cOpYP6fObLNyV4eiMI7UR1xt5sAhsYbS3J4=.4f043e47-02fc-47cb-9ac2-beeff3f12ba4@github.com>
 <PhsfeE7bEv_IAo2gWbS6nUi0K8IMcr0hWjmPUBFy9rg=.c77b06e5-e23c-44d0-9f0b-c8057f272480@github.com>
 <91Wq6atcQ-B9y-oxN4qsk4F80m8jw53pbmzXcVxx_sQ=.18f531f3-921b-48df-8048-550441aa2b95@github.com>
Message-ID: <XW4XWiVMXxs8Mf4hzTxGEGfCnQ-v5WrEp2QJaoq2l40=.f42bb708-d928-4ed9-994e-f1e75ba9bdc4@github.com>

On Mon, 10 Nov 2025 09:38:32 GMT, SendaoYan <syan at openjdk.org> wrote:

>> I'd rather not, since by throwing `SkippedException` the other tests won't run either. It's useful to see various values for the back-mapped value. In this case it should be a value < 1024 which is asserted by the if. Later, we have actual assertions in the test for `1024` and `2048`. Does that make sense?
>
> So does the 'import jtreg.SkippedException;' in file test/hotspot/jtreg/containers/docker/TestMisc.java seems do not needed

Yes, indeed. I'll remove it from `test/hotspot/jtreg/containers/docker/TestMisc.java`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2509756250

From stuefe at openjdk.org  Mon Nov 10 10:34:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 10 Nov 2025 10:34:10 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
Message-ID: <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>

On Mon, 10 Nov 2025 08:46:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order of includes corrected.

Just to understand this right: We already notice buffer over- and underflows, right? So this is just about catching the case where someone writes into the malloc header but does *not* overwrite the actual real malloc area?

Makes sense, since we also want to catch one-byte-overwrites. Though I would probably just disable NMT and do it that way.

src/hotspot/share/nmt/mallocHeader.hpp line 126:

> 124:   inline static OutTypeParam resolve_checked_impl(InTypeParam memblock);
> 125: 
> 126:   void asan_poison_self() {

Why this complex? Why not just poison/unpoison the whole header in one call? You could simplify quite a bit that way.

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

PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3442286623
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2509799450

From jsjolen at openjdk.org  Mon Nov 10 10:39:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Nov 2025 10:39:07 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
Message-ID: <E2h879J5UBTCTHGHRO8b3-VxhAVyR-ZV0LCpruSE5xw=.d82073cb-1aba-42fb-a577-be5a11c829d9@github.com>

On Mon, 10 Nov 2025 08:46:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order of includes corrected.

> Just to understand this right: We already notice buffer over- and underflows, right? So this is just about catching the case where someone writes into the malloc header but does _not_ overwrite the actual real malloc area?
> 
> Makes sense, since we also want to catch one-byte-overwrites. Though I would probably just disable NMT and do it that way.

You've got it right.

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

PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3510757790

From azafari at openjdk.org  Mon Nov 10 11:14:54 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 10 Nov 2025 11:14:54 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <E2h879J5UBTCTHGHRO8b3-VxhAVyR-ZV0LCpruSE5xw=.d82073cb-1aba-42fb-a577-be5a11c829d9@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <E2h879J5UBTCTHGHRO8b3-VxhAVyR-ZV0LCpruSE5xw=.d82073cb-1aba-42fb-a577-be5a11c829d9@github.com>
Message-ID: <-ZMsfT5lAJ7iQKup1J66Io3qg0K0ac_YlIwxl8ec2zo=.db922ffd-cddb-4a0d-bbd7-f3d4103383f4@github.com>

On Mon, 10 Nov 2025 10:36:20 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Makes sense, since we also want to catch one-byte-overwrites. Though I would probably just disable NMT and do it that way.

One big difference here is that NMT detects overflow/underflow only at free-ing the memory. Using ASAN poisoning, we can find the writer/reader immediately. Also, NMT reports the malloc-site (where in the source the memory is allocated) and we don't get any info about where in the code the corruption happened.

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

PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3510937980

From azafari at openjdk.org  Mon Nov 10 11:34:30 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 10 Nov 2025 11:34:30 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
Message-ID: <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>

On Mon, 10 Nov 2025 10:27:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   order of includes corrected.
>
> src/hotspot/share/nmt/mallocHeader.hpp line 126:
> 
>> 124:   inline static OutTypeParam resolve_checked_impl(InTypeParam memblock);
>> 125: 
>> 126:   void asan_poison_self() {
> 
> Why this complex? Why not just poison/unpoison the whole header in one call? You could simplify quite a bit that way.

The only reason is to avoid unpoisoning when accessing other fields as MemTag or MST_Marker, and poisoning back when access is completed. Now MemTag and mst_marker fields are free to be accessed without unpoisoning first.
I can change the issue title and do the whole header poisoning, if it is preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2510115250

From phubner at openjdk.org  Mon Nov 10 12:28:18 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 10 Nov 2025 12:28:18 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
Message-ID: <9zVEC2-b0c1HCCpbfq10eemvBp5f28vPnNc8JqecaGE=.bc9a9ff1-fe5a-4e43-9ee0-dbc210c69c5f@github.com>

On Mon, 10 Nov 2025 08:46:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   order of includes corrected.

Thanks for doing this, Afshin! I've left some very minor comments.

src/hotspot/share/nmt/mallocHeader.hpp line 120:

> 118:   void set_footer(uint16_t v) {
> 119:     AsanPoisoningHelper aph(reinterpret_cast<uint16_t*>(footer_address()));
> 120:     footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v;

Nit: can we please separate these onto two separate lines, it's cumbersome to read.

src/hotspot/share/nmt/mallocHeader.inline.hpp line 63:

> 61:   asan_unpoison_self();
> 62:   set_header_canary(_header_canary_dead_mark);
> 63:   NOT_LP64(set_alt_canary(_header_alt_canary_dead_mark);)

Question: is there a reason why the canaries and alt canaries are set here rather than in the unpoison function? While reviewing I had to jump back and forth between this & the other method to figure out what's going on.

src/hotspot/share/sanitizers/address.hpp line 86:

> 84:   AsanPoisoningHelper(const T* addr) : _memory_region(addr) {
> 85:     #if INCLUDE_ASAN
> 86:       ASAN_UNPOISON_MEMORY_REGION(_memory_region, sizeof(T));

So if I understand correctly, when we do e.g.:

AsanPoisoningHelper aph(reinterpret_cast<uint16_t*>(footer_address()));
footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v;

We are first unpoisoning, doing our memory modification, and then re-poisoning once the helper falls out of scope. Wouldn't it make that an `Asan*Un*poisoningHelper`? Maybe you could introduce a quick comment on what this class is/what you would use it for, because it's a bit counter intuitive at least to me.

test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 325:

> 323:     a = 2;
> 324:     EXPECT_EQ(a, 2);
> 325:   }

Maybe you could add another assert once the helper is out of scope to make sure that there is a death?

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

PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3511312859
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2510327606
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2510310739
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2510333720
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2510342573

From duke at openjdk.org  Mon Nov 10 13:00:55 2025
From: duke at openjdk.org (Anton Artemov)
Date: Mon, 10 Nov 2025 13:00:55 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Added a comment to a boolean arg for enter()
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Removed incorrect assert,
 - 8366659: Fixed merge conflict
 - 8366659: Fixed whitespace.
 - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
 - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=03
  Stats: 374 lines in 3 files changed: 310 ins; 44 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From stuefe at openjdk.org  Mon Nov 10 13:44:18 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 10 Nov 2025 13:44:18 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
Message-ID: <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>

On Mon, 10 Nov 2025 11:31:28 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/mallocHeader.hpp line 126:
>> 
>>> 124:   inline static OutTypeParam resolve_checked_impl(InTypeParam memblock);
>>> 125: 
>>> 126:   void asan_poison_self() {
>> 
>> Why this complex? Why not just poison/unpoison the whole header in one call? You could simplify quite a bit that way.
>
> The only reason is to avoid unpoisoning when accessing other fields as MemTag or MST_Marker, and poisoning back when access is completed. Now MemTag and mst_marker fields are free to be accessed without unpoisoning first.
> I can change the issue title and do the whole header poisoning, if it is preferred.

I see what you mean. 

Ugh. I forgot that we cannot selectively poison write access only but still allow read access, because otherwise poisoning the whole header would be much simpler and nicer. But unpoisoning every time one checks a header would be highly annoying.

In order to simplify, and not to pay too high a penalty on access if ASAN is enabled, I would consider:
- don't bother poisoning `_size`. This field is frequently accessed, as opposed to the `_canary` field. I think cases where we overwrite `_size` but *don't* overwrite either the byte before it (which should be guarded by ASAN anyway since it precedes the first valid byte) or the canary (which is now also poisoned and directly precedes the user payload) should be exceedingly rare. 
- I would just not bother checking NMT block integrity at all if ASAN is enabled. That should reduce the number of accesses to the `_canary` to zero, and since ASAN reports right away when the canary is hit, we will see it right away. Now you won't need unpoisoning on canary read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2510611771

From jsjolen at openjdk.org  Mon Nov 10 14:17:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 10 Nov 2025 14:17:07 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
 <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
Message-ID: <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>

On Mon, 10 Nov 2025 13:38:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The only reason is to avoid unpoisoning when accessing other fields as MemTag or MST_Marker, and poisoning back when access is completed. Now MemTag and mst_marker fields are free to be accessed without unpoisoning first.
>> I can change the issue title and do the whole header poisoning, if it is preferred.
>
> I see what you mean. 
> 
> Ugh. I forgot that we cannot selectively poison write access only but still allow read access, because otherwise poisoning the whole header would be much simpler and nicer. But unpoisoning every time one checks a header would be highly annoying.
> 
> In order to simplify, and not to pay too high a penalty on access if ASAN is enabled, I would consider:
> - don't bother poisoning `_size`. This field is frequently accessed, as opposed to the `_canary` field. I think cases where we overwrite `_size` but *don't* overwrite either the byte before it (which should be guarded by ASAN anyway since it precedes the first valid byte) or the canary (which is now also poisoned and directly precedes the user payload) should be exceedingly rare. 
> - I would just not bother checking NMT block integrity at all if ASAN is enabled. That should reduce the number of accesses to the `_canary` to zero, and since ASAN reports right away when the canary is hit, we will see it right away. Now you won't need unpoisoning on canary read.

Wouldn't this lead to more branches in the code, and questions like "why is this poisoned, but not _size?" etc? I wouldn't call the `_size` field in the header frequently accessed (once at malloc, once at free, any I'm missing?), it's more than 0 I guess :-).

I haven't measured, so grains of salt and so on, but the cost of ASAN is already high, I don't think any additional cost to poisoning/unpoisoning NMT headers at malloc/free is going to add too much of a perf hit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2510735338

From nbenalla at openjdk.org  Mon Nov 10 16:15:38 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 10 Nov 2025 16:15:38 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v4]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Merge branch 'master' into start-of-release-27
 - update links to JVMS 26 and 27
 - add missing enum
 - initial commit start-of-JDK-27

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/b51f2324..0652d5d3

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

  Stats: 164507 lines in 1034 files changed: 112814 ins; 23251 del; 28442 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From iris at openjdk.org  Mon Nov 10 16:35:13 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 10 Nov 2025 16:35:13 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v4]
In-Reply-To: <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <_XezcddmMuD5koE3C1dJPmKhQGSfPHvi0tNBwaUv7oI=.0ffc5492-ca89-43ef-ac6c-b3e44bc11255@github.com>
Message-ID: <4hRkyQC_Dpj1ojQuuFvjJEkFiFqCHqDQm_nnPjDRxfc=.c0a10797-cb7a-4987-9574-0b570acd21b0@github.com>

On Mon, 10 Nov 2025 16:15:38 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - add missing enum
>  - initial commit start-of-JDK-27

Expected changes for JDK 27 looking good.

make/conf/version-numbers.conf line 36:

> 34: DEFAULT_VERSION_EXTRA2=0
> 35: DEFAULT_VERSION_EXTRA3=0
> 36: DEFAULT_VERSION_DATE=2026-09-15

Anticipated GA date confirmed.

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

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

From sgehwolf at openjdk.org  Mon Nov 10 17:45:57 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 10 Nov 2025 17:45:57 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v3]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove SkippedException import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/464d162f..8ba999a9

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

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

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

From duke at openjdk.org  Mon Nov 10 17:56:54 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Nov 2025 17:56:54 GMT
Subject: Withdrawn: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <g5FZM_KaFy7VgRaiJA4dqAWGAyqp82PpKJTHg8tQhs4=.dc8207db-643f-4cd8-a32d-d2599041f373@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Mon Nov 10 18:34:52 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Nov 2025 18:34:52 GMT
Subject: Withdrawn: 8263476: Use reserved memory for stack guard pages
In-Reply-To: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
References: <BojYWaP10BJMEWDQYSRiMKR0cOWzMF5At9_3fwD6uUw=.becf6902-01f1-41e0-965d-18a945a6dfcf@github.com>
Message-ID: <s4KXCoOyb9uSilkgyICzyoEdvku0899N96_oVWuodrw=.b9588dd6-72d1-4794-afd2-759a4967b025@github.com>

On Thu, 31 Jul 2025 10:36:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Use reserved (instead of committed) memory for stack-guard-pages on linux like systems.
> 
> `os::must_commit_stack_guard_pages` uses `commit` in its name, but `commit` usually has specific meanings in OS memory context. The actual question the caller is asking is whether the caller needs to do some preparation work before marking the guard-pages as inaccessible. To avoid confusion, I changed it to "allocate". Other suggestions are welcome.
> 
> Test: ~tier1-3~ tier1-8

This pull request has been closed without being integrated.

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

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

From eastigeevich at openjdk.org  Mon Nov 10 18:48:00 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 10 Nov 2025 18:48:00 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v10]
In-Reply-To: <N4pE0RzjCb8qwt2Tfjsx8WmfpfSA9zeMylRp5rz9pGs=.48775561-bbd3-44af-8561-7e35075b8031@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <N4pE0RzjCb8qwt2Tfjsx8WmfpfSA9zeMylRp5rz9pGs=.48775561-bbd3-44af-8561-7e35075b8031@github.com>
Message-ID: <sBU5jdcORqLARJBOrQ8GVUbFCIOflr7qJh-WDBFV6LM=.6fb24611-c287-4fbf-8ffc-26b5a58f8a0d@github.com>

On Sat, 8 Nov 2025 00:05:38 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unncessary included

test/hotspot/gtest/testutils.cpp line 94:

> 92:   if (address <= (mach_vm_address_t)addr &&
> 93:       (address + region_size) >= ((mach_vm_address_t)addr + size)) {
> 94:     // Check if the user_tag matches VM_MEMORY_JAVA

No need this comment because it just repeats what is written in `return`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2511602937

From eastigeevich at openjdk.org  Mon Nov 10 18:50:51 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 10 Nov 2025 18:50:51 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v10]
In-Reply-To: <N4pE0RzjCb8qwt2Tfjsx8WmfpfSA9zeMylRp5rz9pGs=.48775561-bbd3-44af-8561-7e35075b8031@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <N4pE0RzjCb8qwt2Tfjsx8WmfpfSA9zeMylRp5rz9pGs=.48775561-bbd3-44af-8561-7e35075b8031@github.com>
Message-ID: <n_RBOpxVe5OhuCFNIGtid8gkIHOq8qv_vsRjHZIIxJY=.73d47ae5-3f70-4467-96bf-d2a076b5c488@github.com>

On Sat, 8 Nov 2025 00:05:38 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unncessary included

test/hotspot/gtest/testutils.hpp line 54:

> 52: #ifdef __APPLE__
> 53:   // Check if a memory region is tagged with VM_MEMORY_JAVA on macOS
> 54:   // This function is used by multiple test files to validate BSD memory tagging

Maybe we don't "This function ..." comment line because it might be misleading. The function is used in one test only.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2511610847

From azafari at openjdk.org  Mon Nov 10 19:06:57 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 10 Nov 2025 19:06:57 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <9zVEC2-b0c1HCCpbfq10eemvBp5f28vPnNc8JqecaGE=.bc9a9ff1-fe5a-4e43-9ee0-dbc210c69c5f@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <9zVEC2-b0c1HCCpbfq10eemvBp5f28vPnNc8JqecaGE=.bc9a9ff1-fe5a-4e43-9ee0-dbc210c69c5f@github.com>
Message-ID: <rI0f1xJ8AAVGaFAagi8QZr5W_3qAZWQkiby2wDpIHlc=.59365360-58f8-4fd1-b2fd-dee75313e3ea@github.com>

On Mon, 10 Nov 2025 12:16:14 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   order of includes corrected.
>
> src/hotspot/share/nmt/mallocHeader.inline.hpp line 63:
> 
>> 61:   asan_unpoison_self();
>> 62:   set_header_canary(_header_canary_dead_mark);
>> 63:   NOT_LP64(set_alt_canary(_header_alt_canary_dead_mark);)
> 
> Question: is there a reason why the canaries and alt canaries are set here rather than in the unpoison function? While reviewing I had to jump back and forth between this & the other method to figure out what's going on.

Consider the logic here that when ASAN is not enabled, the malloc-header functionality should proceed. i.e. the canaries to be set as DEAD. When the ASAN is enabled, however, the memory regions for the canaries should be unpoisoned otherwise ASAN assertions raise (since we are writing to poisoned memory region).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2511650981

From azafari at openjdk.org  Mon Nov 10 20:03:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 10 Nov 2025 20:03:35 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v21]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <2UfkSzuxH68EuDt0x5oY_Hy2Mxm3JT68vwTj9MXZW1w=.1e5c9ca2-bfb3-4ddd-82a7-6164516fd239@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  improvements.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27685/files
  - new: https://git.openjdk.org/jdk/pull/27685/files/626fc490..d6cab2bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=19-20

  Stats: 17 lines in 2 files changed: 15 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685

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

From azafari at openjdk.org  Mon Nov 10 20:03:39 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 10 Nov 2025 20:03:39 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <9zVEC2-b0c1HCCpbfq10eemvBp5f28vPnNc8JqecaGE=.bc9a9ff1-fe5a-4e43-9ee0-dbc210c69c5f@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <9zVEC2-b0c1HCCpbfq10eemvBp5f28vPnNc8JqecaGE=.bc9a9ff1-fe5a-4e43-9ee0-dbc210c69c5f@github.com>
Message-ID: <e8QwnVUCidzgDKYACQ039bNoUxrKOWuuKFLOeh3QaTg=.7929b04e-940f-4c99-9081-dfba9a3aea0d@github.com>

On Mon, 10 Nov 2025 12:20:35 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   order of includes corrected.
>
> src/hotspot/share/nmt/mallocHeader.hpp line 120:
> 
>> 118:   void set_footer(uint16_t v) {
>> 119:     AsanPoisoningHelper aph(reinterpret_cast<uint16_t*>(footer_address()));
>> 120:     footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v;
> 
> Nit: can we please separate these onto two separate lines, it's cumbersome to read.

Done.

> src/hotspot/share/sanitizers/address.hpp line 86:
> 
>> 84:   AsanPoisoningHelper(const T* addr) : _memory_region(addr) {
>> 85:     #if INCLUDE_ASAN
>> 86:       ASAN_UNPOISON_MEMORY_REGION(_memory_region, sizeof(T));
> 
> So if I understand correctly, when we do e.g.:
> 
> AsanPoisoningHelper aph(reinterpret_cast<uint16_t*>(footer_address()));
> footer_address()[0] = (uint8_t)(v >> 8); footer_address()[1] = (uint8_t)v;
> 
> We are first unpoisoning, doing our memory modification, and then re-poisoning once the helper falls out of scope. Wouldn't it make that an `Asan*Un*poisoningHelper`? Maybe you could introduce a quick comment on what this class is/what you would use it for, because it's a bit counter intuitive at least to me.

Done.

> test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 325:
> 
>> 323:     a = 2;
>> 324:     EXPECT_EQ(a, 2);
>> 325:   }
> 
> Maybe you could add another assert once the helper is out of scope to make sure that there is a death?

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2511804900
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2511806186
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2511806606

From ayang at openjdk.org  Mon Nov 10 21:25:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 10 Nov 2025 21:25:19 GMT
Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next
Message-ID: <nCSdjRi9SqcR9RThn_F5DmK7peCliid5ZRXL2joRgQk=.8b72311c-435c-488b-ae5c-bebf241dd7b2@github.com>

A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early.

Test: tier1

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

Commit messages:
 - smap-parser

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

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

From ysuenaga at openjdk.org  Tue Nov 11 00:24:04 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 11 Nov 2025 00:24:04 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <-oDd88Q7tk18y-gDNqcma6fgRN_5Kqhjt6XErYjfNfo=.922b1083-276f-45c5-8946-b9f3b3c1dc94@github.com>

On Sun, 2 Nov 2025 06:27:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

PING: Can I get Reviewers?

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3514453905

From dcubed at openjdk.org  Tue Nov 11 02:44:26 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 11 Nov 2025 02:44:26 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
Message-ID: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>

On Mon, 10 Nov 2025 13:00:55 GMT, Anton Artemov <duke at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - 8366659: Fixed whitespace.
>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4

Vaious minor nits here with a couple of queries about why
assert_mark_word_consistency calls were removed.

During my crawl through I ran into quite a few nits and typos,
but I'm putting those in a separate issue.

Thanks for adding two new sub-test cases for better coverage.

src/hotspot/share/runtime/objectMonitor.cpp line 533:

> 531: }
> 532: 
> 533: void ObjectMonitor::enter_with_contention_mark(JavaThread* current, ObjectMonitorContentionMark &cm, bool post_jvmti_events) {

In the baseline also: `cm` is passed in, but it only used for this:
`assert(cm._monitor == this, "must be");`.

This makes me wonder if we're missing some code in `enter_with_contention_mark`
that is normally done when we are passed an `ObjectMonitorContentionMark`.

src/hotspot/share/runtime/objectMonitor.cpp line 1108:

> 1106:   assert(currentNode->_thread == current, "invariant");
> 1107:   assert(_waiters > 0, "invariant");
> 1108:   assert_mark_word_consistency();

Why remove call to `assert_mark_word_consistency();`?

src/hotspot/share/runtime/objectMonitor.cpp line 1186:

> 1184:   // Current has acquired the lock -- Unlink current from the _entry_list.
> 1185:   assert(has_owner(current), "invariant");
> 1186:   assert_mark_word_consistency();

Why remove call to `assert_mark_word_consistency();`?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 387:

> 385:                 }
> 386:                 try { Thread.sleep(1000);
> 387:                 } catch(Exception e) {}

Nit: The `Thread.sleep` call should be on its own line after L386.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 452:

> 450: 
> 451:             try { Thread.sleep(1000);
> 452:             } catch(Exception e) {}

Nit: The Thread.sleep call should be on its own line after L451.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 506:

> 504:                 }
> 505:                 try { Thread.sleep(1000);
> 506:                 } catch(Exception e) {}

Nit: The Thread.sleep call should be on its own line after L505.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3444783084
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2511785347
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2511693213
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2511698003
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2512616795
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2512620831
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2512622710

From syan at openjdk.org  Tue Nov 11 02:57:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 11 Nov 2025 02:57:08 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v3]
In-Reply-To: <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <iXsBU0cKqFLwnH1Zn5F9X2anCrFXg3hXnIzEgfJoDFg=.78353547-8be9-43ed-b485-18da00e7a96b@github.com>
Message-ID: <9_mUShL9w0WJOY_mRnI9Q6kjahjGy5C4r2nskAj84UU=.b998be5a-042f-4bcc-8eae-e5aaf485642c@github.com>

On Mon, 10 Nov 2025 17:45:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove SkippedException import

This fix works for me

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

Marked as reviewed by syan (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3446022550

From lmesnik at openjdk.org  Tue Nov 11 03:58:21 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 03:58:21 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
Message-ID: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>

Please review following fix that move GC shutdown start after VM Death and agent's unloading.

The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.

The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

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

Commit messages:
 - 8367902: Allocation after Universe::before_exit() in the VM shutdown sequence

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

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

From sgehwolf at openjdk.org  Tue Nov 11 09:57:39 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 11 Nov 2025 09:57:39 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Remove SkippedException import
 - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
 - Fix include
 - Add asserts/checks for input domain
 - Add regression test for jdk-8370492
 - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/8ba999a9..a2c6b160

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

  Stats: 152084 lines in 669 files changed: 106238 ins; 18592 del; 27254 mod
  Patch: https://git.openjdk.org/jdk/pull/28157.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28157/head:pull/28157

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

From ayang at openjdk.org  Tue Nov 11 10:06:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Nov 2025 10:06:14 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com>

On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> move GC shutdown start after VM Death and agent's unloading

Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)?

(The current patch would leave GC running while calling `MemMapPrinter::print_all_mappings(tty);` -- GC can potentially alter mappings.)

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

PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3515988219

From stefank at openjdk.org  Tue Nov 11 10:25:43 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 11 Nov 2025 10:25:43 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <0QVCSBQR8WrlEi7MbVIPpwgk5ndxBkTi7i-uK2z8P9U=.b105574d-980d-4303-9186-fece5e73f94d@github.com>

On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

I agree with Albert. I would prefer a patch that moves the JVMTI code instead. This is also what I've tested through tier1-8 in my queue of patches to clean up some of the shutdown code:
https://github.com/stefank/jdk/tree/remove_2s_shutdown_workaround

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

PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3516108702

From sspitsyn at openjdk.org  Tue Nov 11 11:18:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 11 Nov 2025 11:18:49 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>

On Mon, 10 Nov 2025 19:21:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> src/hotspot/share/runtime/objectMonitor.cpp line 1108:
> 
>> 1106:   assert(currentNode->_thread == current, "invariant");
>> 1107:   assert(_waiters > 0, "invariant");
>> 1108:   assert_mark_word_consistency();
> 
> Why remove call to `assert_mark_word_consistency();`?

Same question from me. :)

> src/hotspot/share/runtime/objectMonitor.cpp line 1186:
> 
>> 1184:   // Current has acquired the lock -- Unlink current from the _entry_list.
>> 1185:   assert(has_owner(current), "invariant");
>> 1186:   assert_mark_word_consistency();
> 
> Why remove call to `assert_mark_word_consistency();`?

Same question from me. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513824738
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513824235

From jsjolen at openjdk.org  Tue Nov 11 12:06:27 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 11 Nov 2025 12:06:27 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <OXEkNYzaOEDelZKCoNfsiW_iaxwjdjmcYNFxKbXUDk4=.b3ff559d-af9d-4e6f-8561-a818392bff64@github.com>

On Sun, 2 Nov 2025 06:27:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

Hi,

The actual issue here is that the vDSO file doesn't exist, so can't be opened, right? Then, we should instead check in `get_elf_file` whether the creation of the `ElfFile` succeeded instead. This should be done anyway, the `vDSO` issue is just a symptom of another bug.

I think that this new definition should be used instead, in `decoder_elf.cpp:104`.

```c++
ElfFile* ElfDecoder::get_elf_file(const char* filepath) {
  ElfFile* file;

  file = _opened_elf_files;
  while (file != nullptr) {
    if (file->same_elf_file(filepath)) {
      return file;
    }
    file = file->next();
  }

  file = new (std::nothrow) ElfFile(filepath);
  if (file == nullptr) {
    return nullptr;
  } else if (file->get_status() != NullDecoder::no_error) {
    return nullptr;
  }


  if (_opened_elf_files != nullptr) {
    file->set_next(_opened_elf_files);
  }
  _opened_elf_files = file;

  return file;
}


What do you think?

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

PR Review: https://git.openjdk.org/jdk/pull/28102#pullrequestreview-3447747095

From duke at openjdk.org  Tue Nov 11 12:08:36 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 12:08:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
 <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>
Message-ID: <CPL4peZwOIl4JnzZoTQ7k5LWTEeJ_LXBHU1oEKNnl_E=.529f60de-5c2e-4965-a0a3-c4fd3767953f@github.com>

On Tue, 11 Nov 2025 11:15:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1108:
>> 
>>> 1106:   assert(currentNode->_thread == current, "invariant");
>>> 1107:   assert(_waiters > 0, "invariant");
>>> 1108:   assert_mark_word_consistency();
>> 
>> Why remove call to `assert_mark_word_consistency();`?
>
> Same question from me. :)

This assert only works in a non-blocked state. The call to `reenter_internal` is now done in a blocked state, I also changed the assertion on the state from `!=` to `==` a few lines above it. 

`assert_mark_word_consistency()` calls `object()` which calls `check_object_context()`, which can pass only if the state is either `_thread_in_vm` or `_thread_in_Java`. Since the call is now made from a blocked state, the assert has to be removed. 

`assert_mark_word_consistency()` is called after the thread is back to a non-blocked state.

>> src/hotspot/share/runtime/objectMonitor.cpp line 1186:
>> 
>>> 1184:   // Current has acquired the lock -- Unlink current from the _entry_list.
>>> 1185:   assert(has_owner(current), "invariant");
>>> 1186:   assert_mark_word_consistency();
>> 
>> Why remove call to `assert_mark_word_consistency();`?
>
> Same question from me. :)

Same answer as above, it only works in a non-blocked state, but that is no longer the case here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513991947
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2513993815

From duke at openjdk.org  Tue Nov 11 12:40:44 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 12:40:44 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <sgzJaGb1wmW4ZT3gI2AJ3bWVqst5j4qdSdJR4gCgc9M=.481e4dc0-a773-479d-aa92-3d90a8fcd6af@github.com>

On Mon, 10 Nov 2025 19:53:09 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> src/hotspot/share/runtime/objectMonitor.cpp line 533:
> 
>> 531: }
>> 532: 
>> 533: void ObjectMonitor::enter_with_contention_mark(JavaThread* current, ObjectMonitorContentionMark &cm, bool post_jvmti_events) {
> 
> In the baseline also: `cm` is passed in, but it only used for this:
> `assert(cm._monitor == this, "must be");`.
> 
> This makes me wonder if we're missing some code in `enter_with_contention_mark`
> that is normally done when we are passed an `ObjectMonitorContentionMark`.

Yes, in `enter_with_contention_mark` the mark itself is only for assertion. I agree that is not clear, if there is any issue popping up, we can address it in a separate PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514088683

From duke at openjdk.org  Tue Nov 11 13:13:29 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 13:13:29 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v5]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <7LWuJgkzmagjtR5L5LQxskLT-zyMJKrPsFKy9VRjNF4=.36d14e51-9d61-4cbc-b24b-6d68208158a5@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Fixed lines in tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/31482ba4..7f26302e

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

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

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

From duke at openjdk.org  Tue Nov 11 13:13:34 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 13:13:34 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <LuYRe1Gq0xauwWf07K8Qyj4G5cDhqWTPfxTSMtdpGFQ=.0e8d0a61-830f-423d-9553-36ce10960036@github.com>

On Tue, 11 Nov 2025 02:33:25 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 452:
> 
>> 450: 
>> 451:             try { Thread.sleep(1000);
>> 452:             } catch(Exception e) {}
> 
> Nit: The Thread.sleep call should be on its own line after L451.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 506:
> 
>> 504:                 }
>> 505:                 try { Thread.sleep(1000);
>> 506:                 } catch(Exception e) {}
> 
> Nit: The Thread.sleep call should be on its own line after L505.

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514175972
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514176496

From duke at openjdk.org  Tue Nov 11 13:53:36 2025
From: duke at openjdk.org (Anton Artemov)
Date: Tue, 11 Nov 2025 13:53:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
Message-ID: <D1JFQspsIPPkFVsxI3RgohU2JexIslgudEuV_4negfE=.1b6fee36-8634-4b05-a8bb-97da780e29ff@github.com>

On Tue, 11 Nov 2025 02:31:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - 8366659: Fixed whitespace.
>>  - 8366659: Disabled posting JVMTI events in reenter-etner path of wait. Postponed waited event.
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/79fee607...31482ba4
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 387:
> 
>> 385:                 }
>> 386:                 try { Thread.sleep(1000);
>> 387:                 } catch(Exception e) {}
> 
> Nit: The `Thread.sleep` call should be on its own line after L386.

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2514310008

From lmesnik at openjdk.org  Tue Nov 11 17:26:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 17:26:34 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v2]
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <WuEpIa7R-e5BECyQgh4Ecyf1zFW4Wg0NNg0hklVTgiY=.6bae8127-ad2a-4728-bf7b-4cfb672cf2b1@github.com>

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  moved jvmti/gc coce

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28227/files
  - new: https://git.openjdk.org/jdk/pull/28227/files/a49d67ca..e728034d

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

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

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

From lmesnik at openjdk.org  Tue Nov 11 17:45:27 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 17:45:27 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v3]
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <y87T3KsrPbenVRo0yCDQCtn4HZFcO-vK747sfcPBycA=.53382245-d0cf-48a3-a869-369de6846656@github.com>

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  moving

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28227/files
  - new: https://git.openjdk.org/jdk/pull/28227/files/e728034d..be6eb483

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

  Stats: 14 lines in 2 files changed: 8 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28227.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28227/head:pull/28227

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

From lmesnik at openjdk.org  Tue Nov 11 18:15:23 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 18:15:23 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  dot added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28227/files
  - new: https://git.openjdk.org/jdk/pull/28227/files/be6eb483..6d367b4a

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

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

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

From lmesnik at openjdk.org  Tue Nov 11 18:33:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 11 Nov 2025 18:33:04 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence
In-Reply-To: <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <53ymzoSHFWCq2NSuHUOoabHdtoU_uNHEDb2tshbiDh8=.836d28b5-4625-4c07-90ac-157a14ff7abd@github.com>
Message-ID: <naK6lKFlGDVOuWTfMy_Hf1qHiPPGxgrHQu2bWI1JihQ=.4a71b2a8-60d8-4ba8-b736-1bc690666fa2@github.com>

On Tue, 11 Nov 2025 10:03:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
>> move GC shutdown start after VM Death and agent's unloading
> 
> Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)?
> 
> (The current patch would leave GC running while calling `MemMapPrinter::print_all_mappings(tty);` -- GC can potentially alter mappings.)

@albertnetymk, @stefank 

> > move GC shutdown start after VM Death and agent's unloading
> 
> Is there a reason why `Universe::before_exit()` is moved down, instead of moving jvmti related calls (before `Universe::before_exit()`)?

I updated to move jvmti code. Seems that following opertaions
  WatcherThread::stop();
  NativeHeapTrimmer::cleanup(); 
might be done before sending jvmti vm_death.

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

PR Comment: https://git.openjdk.org/jdk/pull/28227#issuecomment-3518247296

From ayang at openjdk.org  Tue Nov 11 19:05:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Nov 2025 19:05:04 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <r-qyaOQu-GJxX3KyVYwWlxHXxrYfNiGlUdcfyFL1Uls=.e5c240a8-6ffb-445e-8dd6-e63096f040fb@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3449515538

From aboldtch at openjdk.org  Wed Nov 12 07:03:17 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 12 Nov 2025 07:03:17 GMT
Subject: RFR: 8371675: ZGC: Remove leftover X VMOp symbols
Message-ID: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>

Trivial change to remove the VMOp symbols from the `VM_OPS_DO` macro which were left over after the removal of the non-generational ZGC. ([JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850))

* Testing
  * GHA

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

Commit messages:
 - 8371675: ZGC: Remove leftover X VMOp symbols

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

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

From jsikstro at openjdk.org  Wed Nov 12 07:40:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 12 Nov 2025 07:40:03 GMT
Subject: RFR: 8371675: ZGC: Remove leftover X VMOp symbols
In-Reply-To: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
References: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
Message-ID: <NoQVqsbyc8Dg3gkHCDMchjqCW83x1p5Y35J1wO_o1-k=.4e62a85d-1225-4a91-8b09-3d722c8de8ae@github.com>

On Wed, 12 Nov 2025 06:57:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Trivial change to remove the VMOp symbols from the `VM_OPS_DO` macro which were left over after the removal of the non-generational ZGC. ([JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850))
> 
> * Testing
>   * GHA

Marked as reviewed by jsikstro (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28252#pullrequestreview-3452037868

From aboldtch at openjdk.org  Wed Nov 12 07:47:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 12 Nov 2025 07:47:16 GMT
Subject: RFR: 8371681: Remove unused VMOp type CollectForCodeCacheAllocation
Message-ID: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>

The VMOp type `CollectForCodeCacheAllocation` was added with [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) but was never used. More than likely this is some vestigial part from earlier iterations of the Loom project.

I suggest a trivial removal of this unused symbol.

* Testing
   * GHA

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

Commit messages:
 - 8371681: Remove unused VMOp type CollectForCodeCacheAllocation

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

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

From aboldtch at openjdk.org  Wed Nov 12 07:47:44 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 12 Nov 2025 07:47:44 GMT
Subject: RFR: 8371680: JVMTI: Remove unused VMOp type JvmtiPostObjectFree
Message-ID: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>

The VMOp type `JvmtiPostObjectFree` was introduced with [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879) but was never used for any `VM_Operation`. The `VM_Operation` introduced in that patch `VM_JvmtiPostObjectFree` used the `Cleanup` VMOp type instead.

`VM_JvmtiPostObjectFree` was later removed completely with [JDK-8256811](https://bugs.openjdk.org/browse/JDK-8256811). So there is no need for this VMOp type.

I suggest a trivial removal of this unused symbol.

* Testing
  * GHA

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

Commit messages:
 - 8371680: JVMTI: Remove unused VMOp type JvmtiPostObjectFree

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

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

From stefank at openjdk.org  Wed Nov 12 07:52:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 12 Nov 2025 07:52:04 GMT
Subject: RFR: 8371675: ZGC: Remove leftover X VMOp symbols
In-Reply-To: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
References: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
Message-ID: <XpgZnMqYrsIRzkNG-ed98S0H5l2hRJlzdAYY7CWTDo4=.9415fcbf-d5bb-4bcb-befb-9a56e5242925@github.com>

On Wed, 12 Nov 2025 06:57:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Trivial change to remove the VMOp symbols from the `VM_OPS_DO` macro which were left over after the removal of the non-generational ZGC. ([JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850))
> 
> * Testing
>   * GHA

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28252#pullrequestreview-3452078665

From stefank at openjdk.org  Wed Nov 12 07:53:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 12 Nov 2025 07:53:05 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <pv2J4Fp2x-vZq3IzCJVr_fqjhEthtQcAbxeEnJL7mWA=.6a957dad-42ed-4cb8-9366-c6ff436bbb0f@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Looks good and thanks for the test!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452083212

From stefank at openjdk.org  Wed Nov 12 07:55:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 12 Nov 2025 07:55:03 GMT
Subject: RFR: 8371681: Remove unused VMOp type
 CollectForCodeCacheAllocation
In-Reply-To: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
References: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
Message-ID: <y3X4AWpTi82b7csLdnvJ2CLJhO-ARGRtTj48UoYJGz8=.de5de2a9-3c83-4e50-b95c-dd245db8df05@github.com>

On Wed, 12 Nov 2025 07:40:56 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `CollectForCodeCacheAllocation` was added with [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) but was never used. More than likely this is some vestigial part from earlier iterations of the Loom project.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>    * GHA

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28256#pullrequestreview-3452087425

From stefank at openjdk.org  Wed Nov 12 07:55:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 12 Nov 2025 07:55:04 GMT
Subject: RFR: 8371680: JVMTI: Remove unused VMOp type JvmtiPostObjectFree
In-Reply-To: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
References: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
Message-ID: <oBC25aMZhuIAzy2mMpyU4qrgyUxiimbJTVnDtzXZ7hs=.b9e7b40b-dc3f-4c10-b9d7-6a047b9a86f7@github.com>

On Wed, 12 Nov 2025 07:39:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `JvmtiPostObjectFree` was introduced with [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879) but was never used for any `VM_Operation`. The `VM_Operation` introduced in that patch `VM_JvmtiPostObjectFree` used the `Cleanup` VMOp type instead.
> 
> `VM_JvmtiPostObjectFree` was later removed completely with [JDK-8256811](https://bugs.openjdk.org/browse/JDK-8256811). So there is no need for this VMOp type.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>   * GHA

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28254#pullrequestreview-3452086461

From ysuenaga at openjdk.org  Wed Nov 12 08:00:30 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 12 Nov 2025 08:00:30 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM [v2]
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <kUhvFsMMBFpFfevyUK6hUxU-L2NUlPsl1Mt_xf8P5e0=.de44a879-088e-4baf-96ed-f58ff3221c27@github.com>

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:

 - Undo unnecessary change
 - Check the result of opening file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28102/files
  - new: https://git.openjdk.org/jdk/pull/28102/files/afa88a0a..678d57ee

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

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

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

From ysuenaga at openjdk.org  Wed Nov 12 08:05:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 12 Nov 2025 08:05:06 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM [v2]
In-Reply-To: <OXEkNYzaOEDelZKCoNfsiW_iaxwjdjmcYNFxKbXUDk4=.b3ff559d-af9d-4e6f-8561-a818392bff64@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
 <OXEkNYzaOEDelZKCoNfsiW_iaxwjdjmcYNFxKbXUDk4=.b3ff559d-af9d-4e6f-8561-a818392bff64@github.com>
Message-ID: <R5LcvKcidpvrUeERNnyhjE7SOyDRru9u9Na-u5l3qsw=.0a68fda1-b9a6-4209-be30-c9ef7b42878b@github.com>

On Tue, 11 Nov 2025 12:03:01 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Undo unnecessary change
>>  - Check the result of opening file
>
> Hi,
> 
> The actual issue here is that the vDSO file doesn't exist, so can't be opened, right? Then, we should instead check in `get_elf_file` whether the creation of the `ElfFile` succeeded instead. This should be done anyway, the `vDSO` issue is just a symptom of another bug.
> 
> I think that this new definition should be used instead, in `decoder_elf.cpp:104`.
> 
> ```c++
> ElfFile* ElfDecoder::get_elf_file(const char* filepath) {
>   ElfFile* file;
> 
>   file = _opened_elf_files;
>   while (file != nullptr) {
>     if (file->same_elf_file(filepath)) {
>       return file;
>     }
>     file = file->next();
>   }
> 
>   file = new (std::nothrow) ElfFile(filepath);
>   if (file == nullptr) {
>     return nullptr;
>   } else if (file->get_status() != NullDecoder::no_error) {
>     return nullptr;
>   }
> 
> 
>   if (_opened_elf_files != nullptr) {
>     file->set_next(_opened_elf_files);
>   }
>   _opened_elf_files = file;
> 
>   return file;
> }
> 
> 
> What do you think?

@jdksjolen 
> The actual issue here is that the vDSO file doesn't exist, so can't be opened, right? Then, we should instead check in get_elf_file whether the creation of the ElfFile succeeded instead. This should be done anyway, the vDSO issue is just a symptom of another bug.

Yes, you are right.
I added a check whether the library could be opened. It works for vDSO.
I believe libraries which do not exist on file system would not happen except vDSO, but the issue relates to open ELF files could happen by some system breaking (filesystem broken, memory exhausted, and any other unexpected system failure). This change could cover troubles relates to the file.

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

PR Comment: https://git.openjdk.org/jdk/pull/28102#issuecomment-3520542439

From iwalulya at openjdk.org  Wed Nov 12 08:39:05 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 12 Nov 2025 08:39:05 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <BJzN8ZpFEIVPLk8KfCn2ihF5ZMxUBJ9QOtTTaIfrzNQ=.60b9c93c-092c-49f6-a95e-657240948f13@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3452233407

From jsjolen at openjdk.org  Wed Nov 12 10:00:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 12 Nov 2025 10:00:03 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM [v2]
In-Reply-To: <kUhvFsMMBFpFfevyUK6hUxU-L2NUlPsl1Mt_xf8P5e0=.de44a879-088e-4baf-96ed-f58ff3221c27@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
 <kUhvFsMMBFpFfevyUK6hUxU-L2NUlPsl1Mt_xf8P5e0=.de44a879-088e-4baf-96ed-f58ff3221c27@github.com>
Message-ID: <OGsSr8oiES8lLESaqqTNeWze8Jv1wzUTthLc5P1G0fw=.6bbbfadd-4882-4416-8959-f1eea01c56bc@github.com>

On Wed, 12 Nov 2025 08:00:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
>> 
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> C [linux-vdso.so.1+0xe69]
>> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
>> 
>> Retrying call stack printing without source information...
>> 
>> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
>> 
>> 
>> When I checked back trace on GDB, it failed at `assert`.
>> 
>> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
>> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
>> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
>> 
>> 
>> 
>> (gdb) f 13
>> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
>> 536 assert(false, "section header string table should be loaded");
>> 
>> 
>> vDSO is not a regular ELF, so it should be skipped here.
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Undo unnecessary change
>  - Check the result of opening file

LGTM! Thanks

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28102#pullrequestreview-3452582087

From phubner at openjdk.org  Wed Nov 12 10:03:07 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 12 Nov 2025 10:03:07 GMT
Subject: RFR: 8371093: Assert
 "section header string table should be loaded" failed on debug VM [v2]
In-Reply-To: <kUhvFsMMBFpFfevyUK6hUxU-L2NUlPsl1Mt_xf8P5e0=.de44a879-088e-4baf-96ed-f58ff3221c27@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
 <kUhvFsMMBFpFfevyUK6hUxU-L2NUlPsl1Mt_xf8P5e0=.de44a879-088e-4baf-96ed-f58ff3221c27@github.com>
Message-ID: <IherO_rRnY6zG-sz4DoPk8w8YQkao5eu3rmScJY0tkk=.8e6d96b0-e8d3-40d2-a07a-3c370c42187c@github.com>

On Wed, 12 Nov 2025 08:00:30 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
>> 
>> 
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> C [linux-vdso.so.1+0xe69]
>> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
>> 
>> Retrying call stack printing without source information...
>> 
>> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
>> 
>> 
>> When I checked back trace on GDB, it failed at `assert`.
>> 
>> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
>> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
>> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
>> 
>> 
>> 
>> (gdb) f 13
>> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
>> 536 assert(false, "section header string table should be loaded");
>> 
>> 
>> vDSO is not a regular ELF, so it should be skipped here.
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Undo unnecessary change
>  - Check the result of opening file

Thanks for looking into this!

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/28102#pullrequestreview-3452598612

From jsikstro at openjdk.org  Wed Nov 12 10:29:36 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 12 Nov 2025 10:29:36 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads
Message-ID: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>

Hello,

This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.

Testing:
* I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
* Running through Oracle's tier1-2

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

Commit messages:
 - 8371701: Add ability to set NUMA-affinity for threads

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

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

From ayang at openjdk.org  Wed Nov 12 10:55:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Nov 2025 10:55:00 GMT
Subject: RFR: 8371681: Remove unused VMOp type
 CollectForCodeCacheAllocation
In-Reply-To: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
References: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
Message-ID: <0jq_TwG9K5YipjXSlvK62bLTvNnJn9MLI1vEs4R6raY=.58893ed7-bb47-48cd-b71b-02fc5927f260@github.com>

On Wed, 12 Nov 2025 07:40:56 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `CollectForCodeCacheAllocation` was added with [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) but was never used. More than likely this is some vestigial part from earlier iterations of the Loom project.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>    * GHA

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28256#pullrequestreview-3452841467

From ayang at openjdk.org  Wed Nov 12 11:03:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Nov 2025 11:03:04 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads
In-Reply-To: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
Message-ID: <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>

On Wed, 12 Nov 2025 10:22:39 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
> 
> Testing:
> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
> * Running through Oracle's tier1-2

src/hotspot/share/runtime/os.hpp line 537:

> 535: 
> 536:   // NUMA-specific interface
> 537:   static bool   numa_set_thread_affinity(Thread* thread, int node);

How to interpret the returned value? What do you suggest callers do with the return-value?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2517863153

From jsikstro at openjdk.org  Wed Nov 12 11:15:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 12 Nov 2025 11:15:04 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads
In-Reply-To: <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
Message-ID: <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>

On Wed, 12 Nov 2025 10:59:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hello,
>> 
>> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
>> 
>> Testing:
>> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
>> * Running through Oracle's tier1-2
>
> src/hotspot/share/runtime/os.hpp line 537:
> 
>> 535: 
>> 536:   // NUMA-specific interface
>> 537:   static bool   numa_set_thread_affinity(Thread* thread, int node);
> 
> How to interpret the returned value? What do you suggest callers do with the return-value?

I'm seeing the return value as "was this operation successful or not". I could add a comment in the header file with something like the following if you think it would make things clearer.

// Sets the affinity of a thread to the CPUs associated with a NUMA node. Passing node
// as -1 sets the affinity to all CPUs the JVM is allowed to run on. Returns true if
// the thread's affinity has been changed, false otherwise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2517897188

From ayang at openjdk.org  Wed Nov 12 13:12:20 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Nov 2025 13:12:20 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads
In-Reply-To: <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
 <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>
Message-ID: <aj07F3zHxGX2vs_kyveu8l4vR_jTK4v6TSqOJd3DAmg=.034e4a0e-54c0-4f1b-94ca-4f2ce04e3beb@github.com>

On Wed, 12 Nov 2025 11:11:57 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 537:
>> 
>>> 535: 
>>> 536:   // NUMA-specific interface
>>> 537:   static bool   numa_set_thread_affinity(Thread* thread, int node);
>> 
>> How to interpret the returned value? What do you suggest callers do with the return-value?
>
> I'm seeing the return value as "was this operation successful or not". I could add a comment in the header file with something like the following if you think it would make things clearer.
> 
> // Sets the affinity of a thread to the CPUs associated with a NUMA node. Passing node
> // as -1 sets the affinity to all CPUs the JVM is allowed to run on. Returns true if
> // the thread's affinity has been changed, false otherwise.

This interpretation makes sense, but what should callers do with the `false` case?

(In #28262, the return-value is just ignored, isn't it?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2518249758

From duke at openjdk.org  Wed Nov 12 13:29:07 2025
From: duke at openjdk.org (Anton Artemov)
Date: Wed, 12 Nov 2025 13:29:07 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed lines in tests.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Added a comment to a boolean arg for enter()
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Removed incorrect assert,
 - 8366659: Fixed merge conflict
 - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=05
  Stats: 377 lines in 3 files changed: 313 ins; 44 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From jsikstro at openjdk.org  Wed Nov 12 13:38:22 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 12 Nov 2025 13:38:22 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads
In-Reply-To: <aj07F3zHxGX2vs_kyveu8l4vR_jTK4v6TSqOJd3DAmg=.034e4a0e-54c0-4f1b-94ca-4f2ce04e3beb@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
 <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>
 <aj07F3zHxGX2vs_kyveu8l4vR_jTK4v6TSqOJd3DAmg=.034e4a0e-54c0-4f1b-94ca-4f2ce04e3beb@github.com>
Message-ID: <kzjd4pN5cXA8uqHP9jkdmrj5eyVc7csAtfxMATG8ryg=.1f188274-1e9b-478d-97fa-b17153d6d03f@github.com>

On Wed, 12 Nov 2025 13:09:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I'm seeing the return value as "was this operation successful or not". I could add a comment in the header file with something like the following if you think it would make things clearer.
>> 
>> // Sets the affinity of a thread to the CPUs associated with a NUMA node. Passing node
>> // as -1 sets the affinity to all CPUs the JVM is allowed to run on. Returns true if
>> // the thread's affinity has been changed, false otherwise.
>
> This interpretation makes sense, but what should callers do with the `false` case?
> 
> (In #28262, the return-value is just ignored, isn't it?)

Yes we ignore the return value in https://github.com/openjdk/jdk/pull/28262 since the algorithm and functionality works if setting the affinity would fail for some reason. If the return type is false a user could bail or revert to some other strategy. I added the boolean return type as a way for users to have insight into the actual result of the operation, if they care.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2518339218

From aboldtch at openjdk.org  Wed Nov 12 14:06:32 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 12 Nov 2025 14:06:32 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <kRomgJ1rFIcPsIVDtUdACYKSX-dk_IKMeg0qMY0iEqU=.3d5a1146-f760-464e-a5ca-6c347eca9610@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3453617541

From ayang at openjdk.org  Wed Nov 12 14:59:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Nov 2025 14:59:34 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads
In-Reply-To: <kzjd4pN5cXA8uqHP9jkdmrj5eyVc7csAtfxMATG8ryg=.1f188274-1e9b-478d-97fa-b17153d6d03f@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
 <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>
 <aj07F3zHxGX2vs_kyveu8l4vR_jTK4v6TSqOJd3DAmg=.034e4a0e-54c0-4f1b-94ca-4f2ce04e3beb@github.com>
 <kzjd4pN5cXA8uqHP9jkdmrj5eyVc7csAtfxMATG8ryg=.1f188274-1e9b-478d-97fa-b17153d6d03f@github.com>
Message-ID: <MBmGPvCA_Gow-9N9-Tbp6Swl-mLRUtSjfx9Suemqpm8=.60142678-6f9e-4020-ac16-8a43044e0a24@github.com>

On Wed, 12 Nov 2025 13:35:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> This interpretation makes sense, but what should callers do with the `false` case?
>> 
>> (In #28262, the return-value is just ignored, isn't it?)
>
> Yes we ignore the return value in https://github.com/openjdk/jdk/pull/28262 since the algorithm and functionality works if setting the affinity would fail for some reason. If the return type is false a user could bail or revert to some other strategy. I added the boolean return type as a way for users to have insight into the actual result of the operation, if they care.

NUMA affinity is a performance hint, not a requirement. Callers can?t meaningfully react to failure -- retry is unlikely to succeed, and there?s no feasible fallback strategy in most contexts.

> since the algorithm and functionality works if setting the affinity would fail

I can't think of a scenario where numa-affinity affects correctness.

Ofc, this is very subjective. Up to you.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2518645095

From tschatzl at openjdk.org  Wed Nov 12 15:42:12 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 12 Nov 2025 15:42:12 GMT
Subject: RFR: 8371681: Remove unused VMOp type
 CollectForCodeCacheAllocation
In-Reply-To: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
References: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
Message-ID: <Q4uZdLC9hpvBTz_nQ10z2zDZ-WkAoQU5AfCTJ4QqLQw=.0ab278c5-1e9c-4726-8027-b58821c45d94@github.com>

On Wed, 12 Nov 2025 07:40:56 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `CollectForCodeCacheAllocation` was added with [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) but was never used. More than likely this is some vestigial part from earlier iterations of the Loom project.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>    * GHA

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28256#pullrequestreview-3454109708

From tschatzl at openjdk.org  Wed Nov 12 15:42:09 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 12 Nov 2025 15:42:09 GMT
Subject: RFR: 8371675: ZGC: Remove leftover X VMOp symbols
In-Reply-To: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
References: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
Message-ID: <rV2AewxTV2sKTRJ7doPbq7AwevvJv0BYi4HHBtLMjT4=.73f46eea-ce91-48ba-bd17-80d9c9685d5d@github.com>

On Wed, 12 Nov 2025 06:57:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Trivial change to remove the VMOp symbols from the `VM_OPS_DO` macro which were left over after the removal of the non-generational ZGC. ([JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850))
> 
> * Testing
>   * GHA

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28252#pullrequestreview-3454115593

From cnorrbin at openjdk.org  Wed Nov 12 15:42:24 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 12 Nov 2025 15:42:24 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
Message-ID: <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>

On Tue, 11 Nov 2025 09:57:39 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Remove SkippedException import
>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>  - Fix include
>  - Add asserts/checks for input domain
>  - Add regression test for jdk-8370492
>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function

Looks good! We are also starting to see tests failing. Some of the new tests fail on rootless cgroup v1 configurations, see comment.

test/hotspot/jtreg/containers/docker/TestMisc.java line 107:

> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
> 107:         printContainerInfo(1052, 1024, true);

These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
`Resource limits are not supported and ignored on cgroups V1 rootless systems`
and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3454095579
PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2518801888

From lmesnik at openjdk.org  Wed Nov 12 16:11:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Nov 2025 16:11:34 GMT
Subject: RFR: 8371680: JVMTI: Remove unused VMOp type JvmtiPostObjectFree
In-Reply-To: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
References: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
Message-ID: <5KD0LZO-Evj-Tb9QmVkYbMBYQXsTmLPbAlpTDWgti88=.92b943cd-2399-4a7d-b92a-c88ef0e9b624@github.com>

On Wed, 12 Nov 2025 07:39:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `JvmtiPostObjectFree` was introduced with [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879) but was never used for any `VM_Operation`. The `VM_Operation` introduced in that patch `VM_JvmtiPostObjectFree` used the `Cleanup` VMOp type instead.
> 
> `VM_JvmtiPostObjectFree` was later removed completely with [JDK-8256811](https://bugs.openjdk.org/browse/JDK-8256811). So there is no need for this VMOp type.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>   * GHA

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28254#pullrequestreview-3454260122

From jsikstro at openjdk.org  Wed Nov 12 16:12:09 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 12 Nov 2025 16:12:09 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v2]
In-Reply-To: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
Message-ID: <229oFjLJXWpSmxuLOOwPs_wnpM6AsXoxuktyA-VbH3I=.5bb6142d-ea0b-4440-aef3-3d0ff737357a@github.com>

> Hello,
> 
> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
> 
> Testing:
> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
> * Running through Oracle's tier1-2

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Change return type of numa_set_thread_affinity to void

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28261/files
  - new: https://git.openjdk.org/jdk/pull/28261/files/d1dbf02c..905e4da0

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

  Stats: 22 lines in 6 files changed: 5 ins; 7 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28261/head:pull/28261

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

From jsikstro at openjdk.org  Wed Nov 12 16:12:09 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 12 Nov 2025 16:12:09 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v2]
In-Reply-To: <MBmGPvCA_Gow-9N9-Tbp6Swl-mLRUtSjfx9Suemqpm8=.60142678-6f9e-4020-ac16-8a43044e0a24@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
 <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>
 <aj07F3zHxGX2vs_kyveu8l4vR_jTK4v6TSqOJd3DAmg=.034e4a0e-54c0-4f1b-94ca-4f2ce04e3beb@github.com>
 <kzjd4pN5cXA8uqHP9jkdmrj5eyVc7csAtfxMATG8ryg=.1f188274-1e9b-478d-97fa-b17153d6d03f@github.com>
 <MBmGPvCA_Gow-9N9-Tbp6Swl-mLRUtSjfx9Suemqpm8=.60142678-6f9e-4020-ac16-8a43044e0a24@github.com>
Message-ID: <l7KRDbk-onaAKv0RaFZl3S32n4F-ch0MIcVg2W70KZI=.161a8c16-63ef-4674-aaf7-e11b23fc4363@github.com>

On Wed, 12 Nov 2025 14:56:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Yes we ignore the return value in https://github.com/openjdk/jdk/pull/28262 since the algorithm and functionality works if setting the affinity would fail for some reason. If the return type is false a user could bail or revert to some other strategy. I added the boolean return type as a way for users to have insight into the actual result of the operation, if they care.
>
> NUMA affinity is a performance hint, not a requirement. Callers can?t meaningfully react to failure -- retry is unlikely to succeed, and there?s no feasible fallback strategy in most contexts.
> 
>> since the algorithm and functionality works if setting the affinity would fail
> 
> I can't think of a scenario where numa-affinity affects correctness.
> 
> Ofc, this is very subjective. Up to you.

I see what you're saying. I'll change the return type to void instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2518912853

From sgehwolf at openjdk.org  Wed Nov 12 16:40:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 16:40:42 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
 <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
Message-ID: <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>

On Wed, 12 Nov 2025 15:36:29 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Remove SkippedException import
>>  - Merge branch 'master' into jdk-8370492-fix-cpushares-mapping
>>  - Fix include
>>  - Add asserts/checks for input domain
>>  - Add regression test for jdk-8370492
>>  - 8370492: [Linux] Update cpu shares to cpu.weight mapping function
>
> test/hotspot/jtreg/containers/docker/TestMisc.java line 107:
> 
>> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
>> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
>> 107:         printContainerInfo(1052, 1024, true);
> 
> These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
> `Resource limits are not supported and ignored on cgroups V1 rootless systems`
> and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.

OK. Thanks for the heads-up. I'll test it. We have infra to check for rootless and can skip it there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2519021505

From stefank at openjdk.org  Wed Nov 12 16:54:29 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 12 Nov 2025 16:54:29 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v2]
In-Reply-To: <l7KRDbk-onaAKv0RaFZl3S32n4F-ch0MIcVg2W70KZI=.161a8c16-63ef-4674-aaf7-e11b23fc4363@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
 <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>
 <aj07F3zHxGX2vs_kyveu8l4vR_jTK4v6TSqOJd3DAmg=.034e4a0e-54c0-4f1b-94ca-4f2ce04e3beb@github.com>
 <kzjd4pN5cXA8uqHP9jkdmrj5eyVc7csAtfxMATG8ryg=.1f188274-1e9b-478d-97fa-b17153d6d03f@github.com>
 <MBmGPvCA_Gow-9N9-Tbp6Swl-mLRUtSjfx9Suemqpm8=.60142678-6f9e-4020-ac16-8a43044e0a24@github.com>
 <l7KRDbk-onaAKv0RaFZl3S32n4F-ch0MIcVg2W70KZI=.161a8c16-63ef-4674-aaf7-e11b23fc4363@github.com>
Message-ID: <kzGQQZU3kZmESRYvLB--CRLz181JbY4IVLCSOLiEBKw=.d89fbfdb-16bc-4977-bf53-9c097125b9ec@github.com>

On Wed, 12 Nov 2025 16:06:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> NUMA affinity is a performance hint, not a requirement. Callers can?t meaningfully react to failure -- retry is unlikely to succeed, and there?s no feasible fallback strategy in most contexts.
>> 
>>> since the algorithm and functionality works if setting the affinity would fail
>> 
>> I can't think of a scenario where numa-affinity affects correctness.
>> 
>> Ofc, this is very subjective. Up to you.
>
> I see what you're saying. I'll change the return type to void instead.

Could one use-case could be to log a failure message and then not try again?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2519076551

From dcubed at openjdk.org  Wed Nov 12 17:17:18 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 17:17:18 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v4]
In-Reply-To: <sgzJaGb1wmW4ZT3gI2AJ3bWVqst5j4qdSdJR4gCgc9M=.481e4dc0-a773-479d-aa92-3d90a8fcd6af@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
 <sgzJaGb1wmW4ZT3gI2AJ3bWVqst5j4qdSdJR4gCgc9M=.481e4dc0-a773-479d-aa92-3d90a8fcd6af@github.com>
Message-ID: <88Sy8kwrXhq7vxLgsKOghkK51dK06psHKkJkcjtayV4=.6895c4a5-02ae-44dc-b620-3d9890078fa3@github.com>

On Tue, 11 Nov 2025 12:37:57 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 533:
>> 
>>> 531: }
>>> 532: 
>>> 533: void ObjectMonitor::enter_with_contention_mark(JavaThread* current, ObjectMonitorContentionMark &cm, bool post_jvmti_events) {
>> 
>> In the baseline also: `cm` is passed in, but it only used for this:
>> `assert(cm._monitor == this, "must be");`.
>> 
>> This makes me wonder if we're missing some code in `enter_with_contention_mark`
>> that is normally done when we are passed an `ObjectMonitorContentionMark`.
>
> Yes, in `enter_with_contention_mark` the mark itself is only for assertion. I agree that is not clear, if there is any issue popping up, we can address it in a separate PR.

I took another look and since we don't do anything with `DEFLATER_MARKER`
in this code path, I concur that we are not missing any code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519150311

From dcubed at openjdk.org  Wed Nov 12 17:17:19 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 17:17:19 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <CPL4peZwOIl4JnzZoTQ7k5LWTEeJ_LXBHU1oEKNnl_E=.529f60de-5c2e-4965-a0a3-c4fd3767953f@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <_V6XFQPX73Cy4NPUqaiSI4mgWSmjjhc1W__bpDmk5eM=.e3279b3d-0770-446b-8e37-35fd00093863@github.com>
 <i_a5U9FxTtBa5rLwtL6qhifTpgvb4Up5t2wItqBl6HU=.da7dd77a-8383-4b30-af20-4db3271d9eb9@github.com>
 <Ot6v4leCoLq4d-7WSS0AcxdOYy0iBb8P4f8E0YL6lEY=.b10f1133-0b63-472f-ae68-acefcb8fa84c@github.com>
 <CPL4peZwOIl4JnzZoTQ7k5LWTEeJ_LXBHU1oEKNnl_E=.529f60de-5c2e-4965-a0a3-c4fd3767953f@github.com>
Message-ID: <T9XYl901YPq1pIVmw3e5GIWZHBg_EVUbatUd5_YwTOY=.f25faea6-2fc8-4e5b-aa94-740a3a43e92b@github.com>

On Tue, 11 Nov 2025 12:05:10 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Same question from me. :)
>
> This assert only works in a non-blocked state. The call to `reenter_internal` is now done in a blocked state, I also changed the assertion on the state from `!=` to `==` a few lines above this line. 
> 
> `assert_mark_word_consistency()` calls `object()` which calls `check_object_context()`, which can pass only if the state is either `_thread_in_vm` or `_thread_in_Java`. Since the call is now made from a blocked state, the assert has to be removed. 
> 
> `assert_mark_word_consistency()` is called after the thread is back to a non-blocked state.

Thanks for the explanation!

Please add a comment above line 341:


// Can only be called from _thread_in_vm or _thread_in_Java due to object() call:
341: #define assert_mark_word_consistency()                                         \
342:   assert(UseObjectMonitorTable || object()->mark() == markWord::encode(this),  \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519143235

From sspitsyn at openjdk.org  Wed Nov 12 18:33:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 12 Nov 2025 18:33:46 GMT
Subject: RFR: 8367902: Allocation after Universe::before_exit() in the VM
 shutdown sequence [v4]
In-Reply-To: <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
 <LASA9p7MeK4BoRft_ysMstr9X0batSXSqolvEYkFieA=.b221e8d5-b751-47c0-8b6e-1017e054bcc3@github.com>
Message-ID: <CLJ_kjOEHbkHTtR-9PWNvA47lYgoxsOy1I5Q-F0FerU=.31a7e113-6103-4ee4-a3cd-b505e609b68b@github.com>

On Tue, 11 Nov 2025 18:15:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
>> 
>> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
>> 
>> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dot added

Looks good. Thank you for fixing this issue!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28227#pullrequestreview-3454892220

From lmesnik at openjdk.org  Wed Nov 12 18:58:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 12 Nov 2025 18:58:04 GMT
Subject: Integrated: 8367902: Allocation after Universe::before_exit() in the
 VM shutdown sequence
In-Reply-To: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
References: <UbZbwGAo4j1Mn6iItNE-oWE2E57q0AHtlLAY5NfgCSU=.41de6622-e613-422f-bcbc-407f33097b6f@github.com>
Message-ID: <x05j3QvDn2P4VgFmEBRWUKGb8-9gOAZ_dyjkQhWv_uo=.a8cf6064-a3b1-47e9-b6e3-42cb247b9028@github.com>

On Tue, 11 Nov 2025 03:49:07 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Please review following fix that move GC shutdown start after VM Death and agent's unloading.
> 
> The `Universe::before_exit();` switch GC to fail any new GC allocation. So any allocation in vm death is failing.
> 
> The test is a little bit complicated because jtreg uses wrapper even to execute othrevm tests and also results might be confusing if test is failing after main() method is completed. So the better is to run new process for vm death event handling.

This pull request has now been integrated.

Changeset: 705bd6fb
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/705bd6fbdc0e78625d05dbfa8af547c50b076e69
Stats:     161 lines in 3 files changed: 151 ins; 9 del; 1 mod

8367902: Allocation after Universe::before_exit() in the VM shutdown sequence

Reviewed-by: ayang, stefank, iwalulya, aboldtch, sspitsyn

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

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

From ayang at openjdk.org  Wed Nov 12 19:14:08 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Nov 2025 19:14:08 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v2]
In-Reply-To: <kzGQQZU3kZmESRYvLB--CRLz181JbY4IVLCSOLiEBKw=.d89fbfdb-16bc-4977-bf53-9c097125b9ec@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <d182a3Mp_lzXgIcsg2z_CfRo6hCkpSkQw5anceG6A80=.e4999c87-d8c9-4a71-90bb-33b8b0c14cbe@github.com>
 <ymqh41WXdkhw9B2hB3CkMjxhy7hWNirxCAB69VYVjWg=.7b8bda13-efb3-404c-8678-1b05db909af6@github.com>
 <aj07F3zHxGX2vs_kyveu8l4vR_jTK4v6TSqOJd3DAmg=.034e4a0e-54c0-4f1b-94ca-4f2ce04e3beb@github.com>
 <kzjd4pN5cXA8uqHP9jkdmrj5eyVc7csAtfxMATG8ryg=.1f188274-1e9b-478d-97fa-b17153d6d03f@github.com>
 <MBmGPvCA_Gow-9N9-Tbp6Swl-mLRUtSjfx9Suemqpm8=.60142678-6f9e-4020-ac16-8a43044e0a24@github.com>
 <l7KRDbk-onaAKv0RaFZl3S32n4F-ch0MIcVg2W70KZI=.161a8c16-63ef-4674-aaf7-e11b23fc4363@github.com>
 <kzGQQZU3kZmESRYvLB--CRLz181JbY4IVLCSOLiEBKw=.d89fbfdb-16bc-4977-bf53-9c097125b9ec@github.com>
Message-ID: <rTFvtuHbLiBxKqgC_G20knnNT8HOiY8qKgRLurZP1b4=.03190756-6db0-4c3e-b9f3-08e9da8a67b5@github.com>

On Wed, 12 Nov 2025 16:51:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I see what you're saying. I'll change the return type to void instead.
>
> Could one use-case could be to log a failure message and then not try again?

Such logic (logging + skip) would complicate the consumer flow with little gain -- failure in this (kind of) API should be no-op (as if skipped).

Also not-try-again assumes future calls always fail, but I'm not sure if that holds. Logging a failure might be interesting, but it should probably be done at OS level, as we use `false` to mean either failure or unsupported.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28261#discussion_r2519486835

From dcubed at openjdk.org  Wed Nov 12 20:09:31 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 20:09:31 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

I've done another crawl thru review. Thanks for making changes after the first
round of comments. In this crawl-thru, my deep focus was on the modified test.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 297:

> 295:     }
> 296: 
> 297:     // Notify the resumer while holding the threadLock

Nit: please add a period at the end of this sentence.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 372:

> 370:                 // - a threadLock enter in the resumer thread
> 371:                 // - resumption of the waiter thread
> 372:                 // - a threadLock enter in the freshly resumed waiter thread

This list of step tests is identical to the list on L490 -> L493 and the
original llist on L256 -> L259.

This step comment:
`370:               // - a threadLock enter in the resumer thread`
should be updated to something like:

             // - a blocked threadLock enter in the resumer thread while the
             //   threadLock is held by the main thread.


This change of threadLock scope also requires this update from:

605:        // - tries to grab the threadLock (should not block!)


to:

605:        // - tries to grab the threadLock (should not block with doWork1!)

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 388:

> 386:                 try {
> 387:                     Thread.sleep(1000);
> 388:                 } catch(Exception e) {}

Why is this 1 second delay needed?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:

> 426:             // launch the waiter thread
> 427:             synchronized (barrierLaunch) {
> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);

This change to `wait` for `1` instead of `0` requires this comment to be updated from:

                // TS_READY_TO_NOTIFY is set after the main thread has
                // entered threadLock so a spurious wakeup can't get the
                // waiter thread out of this threadLock.wait(0) call:

to:

                // TS_READY_TO_NOTIFY is set after the main thread has
                // entered threadLock so a spurious wakeup can't get the
                // waiter thread out of this threadLock.wait(0) call in
                // doWork1 or doWork2. doWork3 passes a one so that the
                // wait() can terminate early and block on reentry.


I'm having trouble seeing why this third test case is necessary. We do a short `wait(1)`
in this test case instead of a `wait(0)` so we terminate the `wait(1)` with a timeout instead
of a `notify()` from the main thread. 

In all worker test cases, the main thread grabs the threadsLock when the "waiter" thread
calls `wait()`, the main thread does a `notify()`, the main thread waits until the worker
thread contends on threadsLock and finally the main thread suspends the worker thread.
The only thing that I see that the `wait(1)` brings to the party is that the worker3 thread
might get to re-entry block on threadsLock via a timeout instead of a notify.

What am I missing here?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 454:

> 452:             try {
> 453:                 Thread.sleep(1000);
> 454:             } catch(Exception e) {}

Why is this 1 second delay needed?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 493:

> 491:                 // - a threadLock enter in the resumer thread
> 492:                 // - resumption of the waiter thread
> 493:                 // - a threadLock enter in the freshly resumed waiter thread

This list of step tests is identical to the list on L369 -> L372 and the
original llist on L256 -> L259.

This step comment:

491:               // - a threadLock enter in the resumer thread

should be updated to something like:

             // - a blocked threadLock enter in the resumer thread while the
             //   threadLock is held by the main thread.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 509:

> 507:                 try {
> 508:                     Thread.sleep(1000);
> 509:                 } catch(Exception e) {}

Why is this 1 second delay needed?

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3454633483
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519187101
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519214534
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519476007
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519522596
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519194484
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519205810
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519483650

From dcubed at openjdk.org  Wed Nov 12 20:09:32 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 12 Nov 2025 20:09:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
Message-ID: <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>

On Wed, 12 Nov 2025 17:36:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 372:
> 
>> 370:                 // - a threadLock enter in the resumer thread
>> 371:                 // - resumption of the waiter thread
>> 372:                 // - a threadLock enter in the freshly resumed waiter thread
> 
> This list of step tests is identical to the list on L490 -> L493 and the
> original llist on L256 -> L259.
> 
> This step comment:
> `370:               // - a threadLock enter in the resumer thread`
> should be updated to something like:
> 
>              // - a blocked threadLock enter in the resumer thread while the
>              //   threadLock is held by the main thread.
> 
> 
> This change of threadLock scope also requires this update from:
> 
> 605:        // - tries to grab the threadLock (should not block!)
> 
> 
> to:
> 
> 605:        // - tries to grab the threadLock (should not block with doWork1!)

I can't figure out why we're delaying the resumer thread in `doWork2`.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 493:
> 
>> 491:                 // - a threadLock enter in the resumer thread
>> 492:                 // - resumption of the waiter thread
>> 493:                 // - a threadLock enter in the freshly resumed waiter thread
> 
> This list of step tests is identical to the list on L369 -> L372 and the
> original llist on L256 -> L259.
> 
> This step comment:
> 
> 491:               // - a threadLock enter in the resumer thread
> 
> should be updated to something like:
> 
>              // - a blocked threadLock enter in the resumer thread while the
>              //   threadLock is held by the main thread.

I can't figure out why we're delaying the resumer thread in `doWork3`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519645665
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2519646704

From sgehwolf at openjdk.org  Wed Nov 12 20:28:41 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 20:28:41 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Fix TestMisc for podman on cg v1 in rootless mode.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28157/files
  - new: https://git.openjdk.org/jdk/pull/28157/files/a2c6b160..9417bdbe

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

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

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

From sgehwolf at openjdk.org  Wed Nov 12 20:28:42 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Nov 2025 20:28:42 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v4]
In-Reply-To: <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <q-HgkC-ZBtpJ9s21L75nD2EPMQNEslMhVjGP1svUPGo=.2176d935-f384-4f13-8c92-ccb22da6a8cf@github.com>
 <aq-SR9lQu8wQE7mZlueMIu58EFF_8s8M7q7rs3_E5MI=.7f6aca5a-4a04-49fb-a597-d05fb9475d90@github.com>
 <uuwGNXE09dUJswJZF04OEl3jhX5socgZ8GRjQROUprw=.eb396bb1-d2b6-401a-8a71-9b62589a716a@github.com>
Message-ID: <F44-sGqpPOFeUpz7wsxljtDtFiDzBaYwQ93l6faWR6g=.15546430-d8be-4459-82bb-a41c5a16e82c@github.com>

On Wed, 12 Nov 2025 16:37:30 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/hotspot/jtreg/containers/docker/TestMisc.java line 107:
>> 
>>> 105:         // Don't use 1024 exactly so as to avoid mapping to the unlimited/uset case.
>>> 106:         // Use a value > 100 post-mapping so as to hit the non-default branch: 1052 => 103
>>> 107:         printContainerInfo(1052, 1024, true);
>> 
>> These tests fail in rootless Podman containers using cgroup v1, because that configuration does not support resource limits. We get the following error to stderr:
>> `Resource limits are not supported and ignored on cgroups V1 rootless systems`
>> and the cpu shares value is reset to 1024. `cpu_shares: no shares` is then in the output, leading to the first test failing. Then, `1024 != 1052` which leads to the second test failing.
>
> OK. Thanks for the heads-up. I'll test it. We have infra to check for rootless and can skip it there.

Should be fixed in the update with: https://github.com/openjdk/jdk/pull/28157/commits/9417bdbeb4d458489953a54d253e8f79dc678734

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28157#discussion_r2519710367

From ysuenaga at openjdk.org  Thu Nov 13 04:32:15 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 13 Nov 2025 04:32:15 GMT
Subject: Integrated: 8371093: Assert
 "section header string table should be loaded" failed on debug VM
In-Reply-To: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
References: <IxS-g_rrLCf2q7Z_uyjZnZDw-GAuGANr9WgFfFPP33o=.7133cd83-aa1e-4ad5-808f-b48f9825a955@github.com>
Message-ID: <23bhO2TY9lB27WoGDvXinsr8-N2DjjLZRpsuHdXLbZo=.34156c62-6d67-46a5-a99e-3361e38340aa@github.com>

On Sun, 2 Nov 2025 06:27:50 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> When the crash happens in the function in vDSO on Linux, native call stacks in hs_err log wouldn't be generated as following. See [hs_err log on JBS](https://bugs.openjdk.org/secure/attachment/116796/hs_err_pid4018.log) for details. Reproducer is also attached on JBS ([Test.java](https://bugs.openjdk.org/secure/attachment/116797/Test.java))
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> C [linux-vdso.so.1+0xe69]
> [error occurred during error reporting (printing native stack (with source info)), id 0xe0000000, Internal Error (/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536)]
> 
> Retrying call stack printing without source information...
> 
> [error occurred during error reporting (retry printing native stack (no source info)), id 0xb, SIGSEGV (0xb) at pc=0x00007fba8075f791]
> 
> 
> When I checked back trace on GDB, it failed at `assert`.
> 
> #12 0x00007fba7e76bd00 in report_vm_error (file=file at entry=0x7fba7fed7b40 "/home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp",
>     line=line at entry=536, error_msg=error_msg at entry=0x7fba80019575 "assert(false) failed",
>     detail_fmt=detail_fmt at entry=0x7fba7fed7bf0 "section header string table should be loaded")
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/debug.cpp:196
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> #14 ElfFile::read_debug_info (this=this at entry=0x7fba782a1650, debug_info=debug_info at entry=0x7fba7dd05150)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:407
> 
> 
> 
> (gdb) f 13
> #13 0x00007fba7e886eb3 in ElfFile::read_section_header (this=0x7fba782a1650, name=0x7fba800367d4 ".gnu_debuglink", hdr=...)
>     at /home/yasuenag/github-forked/jdk/src/hotspot/share/utilities/elfFile.cpp:536
> 536 assert(false, "section header string table should be loaded");
> 
> 
> vDSO is not a regular ELF, so it should be skipped here.

This pull request has now been integrated.

Changeset: b6ba1ac9
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b6ba1ac9aa800e01e2235c2b8737ad4670b0a655
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8371093: Assert "section header string table should be loaded" failed on debug VM

Reviewed-by: phubner, jsjolen

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

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

From aboldtch at openjdk.org  Thu Nov 13 06:20:15 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Nov 2025 06:20:15 GMT
Subject: RFR: 8371680: JVMTI: Remove unused VMOp type JvmtiPostObjectFree
In-Reply-To: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
References: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
Message-ID: <YdDtNHIj8oky76CUUZZ1OuZpmQZff2Wm_1ilAC-v_RQ=.fd964e2e-3edf-4cb0-bdbb-c20e257cbd71@github.com>

On Wed, 12 Nov 2025 07:39:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `JvmtiPostObjectFree` was introduced with [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879) but was never used for any `VM_Operation`. The `VM_Operation` introduced in that patch `VM_JvmtiPostObjectFree` used the `Cleanup` VMOp type instead.
> 
> `VM_JvmtiPostObjectFree` was later removed completely with [JDK-8256811](https://bugs.openjdk.org/browse/JDK-8256811). So there is no need for this VMOp type.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>   * GHA

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28254#issuecomment-3525678161

From aboldtch at openjdk.org  Thu Nov 13 06:20:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Nov 2025 06:20:16 GMT
Subject: Integrated: 8371680: JVMTI: Remove unused VMOp type
 JvmtiPostObjectFree
In-Reply-To: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
References: <xW3JUlniggqMCQWgeua_E5nAIiu1PBd0PF8_7KtMJCI=.909af174-c892-478f-bfb7-b9c04d210efd@github.com>
Message-ID: <smD3F-gAzf2Qu6cEKAmz5qB9OCLTm0jcxgH2iAyfjjw=.47091ac1-1f39-438f-9141-1e6197c886f7@github.com>

On Wed, 12 Nov 2025 07:39:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `JvmtiPostObjectFree` was introduced with [JDK-8212879](https://bugs.openjdk.org/browse/JDK-8212879) but was never used for any `VM_Operation`. The `VM_Operation` introduced in that patch `VM_JvmtiPostObjectFree` used the `Cleanup` VMOp type instead.
> 
> `VM_JvmtiPostObjectFree` was later removed completely with [JDK-8256811](https://bugs.openjdk.org/browse/JDK-8256811). So there is no need for this VMOp type.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>   * GHA

This pull request has now been integrated.

Changeset: 42aecc40
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42aecc4070e952ed6308ebefaf716e35fed2f929
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8371680: JVMTI: Remove unused VMOp type JvmtiPostObjectFree

Reviewed-by: stefank, lmesnik

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

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

From aboldtch at openjdk.org  Thu Nov 13 06:20:17 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Nov 2025 06:20:17 GMT
Subject: Integrated: 8371675: ZGC: Remove leftover X VMOp symbols
In-Reply-To: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
References: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
Message-ID: <i8udYXovs3_lG0hCskwebeIdTyl1OQ0H50rCC8j-03I=.f7fc3ec6-ea9d-4103-9107-e269114ad0e4@github.com>

On Wed, 12 Nov 2025 06:57:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Trivial change to remove the VMOp symbols from the `VM_OPS_DO` macro which were left over after the removal of the non-generational ZGC. ([JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850))
> 
> * Testing
>   * GHA

This pull request has now been integrated.

Changeset: d91480b9
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d91480b9b0f85aca8d9dba615ae5a27f26ce5fee
Stats:     4 lines in 1 file changed: 0 ins; 4 del; 0 mod

8371675: ZGC: Remove leftover X VMOp symbols

Reviewed-by: jsikstro, stefank, tschatzl

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

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

From aboldtch at openjdk.org  Thu Nov 13 06:20:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Nov 2025 06:20:16 GMT
Subject: RFR: 8371675: ZGC: Remove leftover X VMOp symbols
In-Reply-To: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
References: <_aD1g3W5e3DeLRnnmxY30iKukuUEOIrdsjQGKFVIgo4=.50d663a3-8c2e-4175-b0f9-d39b15b16412@github.com>
Message-ID: <JaEJeib1ag5QU21sA_Elqdg2UMi8n3Q5J6S4x0GsOI8=.0be0ced5-5c64-4755-9982-43d4c778a45e@github.com>

On Wed, 12 Nov 2025 06:57:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Trivial change to remove the VMOp symbols from the `VM_OPS_DO` macro which were left over after the removal of the non-generational ZGC. ([JDK-8335850](https://bugs.openjdk.org/browse/JDK-8335850))
> 
> * Testing
>   * GHA

Thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/28252#issuecomment-3525679286

From aboldtch at openjdk.org  Thu Nov 13 06:21:18 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Nov 2025 06:21:18 GMT
Subject: RFR: 8371681: Remove unused VMOp type
 CollectForCodeCacheAllocation
In-Reply-To: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
References: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
Message-ID: <kw9bQ_StqA6RWvraW90glozw0mP1DVR0eN9TzZ2Y3_M=.3cbc2ad8-d6f3-4699-9ae4-ce001a8852a5@github.com>

On Wed, 12 Nov 2025 07:40:56 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `CollectForCodeCacheAllocation` was added with [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) but was never used. More than likely this is some vestigial part from earlier iterations of the Loom project.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>    * GHA

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28256#issuecomment-3525682153

From aboldtch at openjdk.org  Thu Nov 13 06:21:19 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Nov 2025 06:21:19 GMT
Subject: Integrated: 8371681: Remove unused VMOp type
 CollectForCodeCacheAllocation
In-Reply-To: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
References: <5Ot9P7NL4rAfb3R5_ASNAjHIrJIme8JQmorG6kEdCVs=.25d68010-cb21-4319-8136-3722bf98e823@github.com>
Message-ID: <l3mioJXAkxsYZBvO05mdRMjIhmtrzILX8LUDo5edXMo=.3c6f5c60-441c-4627-9b55-5d0e59f39acb@github.com>

On Wed, 12 Nov 2025 07:40:56 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The VMOp type `CollectForCodeCacheAllocation` was added with [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161) but was never used. More than likely this is some vestigial part from earlier iterations of the Loom project.
> 
> I suggest a trivial removal of this unused symbol.
> 
> * Testing
>    * GHA

This pull request has now been integrated.

Changeset: 279f39f1
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/279f39f14a6329d0147613edc3836b7d6d043186
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8371681: Remove unused VMOp type CollectForCodeCacheAllocation

Reviewed-by: stefank, ayang, tschatzl

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

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

From aboldtch at openjdk.org  Thu Nov 13 07:20:28 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 13 Nov 2025 07:20:28 GMT
Subject: RFR: 8371762: Incorrect use of checked_cast in
 Arguments::process_settings_file
Message-ID: <fI3YSAZfE0YWoISEl8PjD6k2ljs1Dg0Rz6-PSCbHAz8=.efc8d2a0-443e-4535-be5a-fa90a33b8f3f@github.com>

[JDK-8313882](https://bugs.openjdk.org/browse/JDK-8313882) introduced a `checked_cast` when to silence the Wconversion warnings when we store an `int` in a `char`. The problem is that the assumption that the value in the `int` we get from `getc` is compatible with `char` is incorrect.

The specification for `getc` is that it returns either `EOF` or the next read `unsigned char` converted to an `int`. This means we have the possible values of `{EOF, 0-255}`, we always check for `EOF` first, so we end up only having `{0-255}` as the possible values. (While a char has the possible values of `{-128-127}`.)

So first the problem with `checked_cast` (which ensures that the type roundtrip is lossless) will end up converting any value in `{128-255}` to `{-128, -1}` which when converted back to an `int` is `{-128, -1}` and not `{128-255}`.

The thing is that this is not a problem except for the assert as we do not care if the conversion roundtrip is lossless. We only want to reinterpret the value as a `char`, and never try to regain the unsigned representation converted to an `int` that `getc` uses.

Another issue with keeping the value inside an `int` which could lead to bugs in the future is that when we use it in equality comparison agains a `char` we will encounter an integer promotion of the `char` which will lead to surprising incorrect results if the character is non-ascii.

Currently we have no such comparisons of this `int` vs a non-ascii character. So the only issue is the assert inside `checked_cast` which will trigger if the settings file contains a non-ascii character.

I suggest we convert the return value from `getc` to a `char` after we have check for `EOF` and before we use it as a character.

It is worth noting that the `(unsigned char)` casts for the calls into `isspace` (introduced by [JDK-8332400](https://bugs.openjdk.org/browse/JDK-8332400)) is very important to get the correct value for its `int` input parameter. (So we get the correct non-sign extended cast `char -> unsigned char -> int`.) That issue mentions the possibility of introducing our own `isspace` (suggestion was `os::isspace`) which we could overload the different types and do the correct thing with bound checks. This might be something we want to revisit.

_`isspace` specification:_
>The behavior is undefined if the value of ch is not representable as unsigned char and is not equal to [EOF](https://en.cppreference.com/w/c/io.html).

* Testing
  * GHA
  * Running tier 1-3 on Oracle supported platforms
  * Manual verification with settings file containing non-ascii characters

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

Commit messages:
 - 8371762: Incorrect use of checked_cast in Arguments::process_settings_file

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

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

From jsikstro at openjdk.org  Thu Nov 13 08:17:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 13 Nov 2025 08:17:21 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
Message-ID: <vubHf5OaEGwMJrk5evTE5iaD-AvyG4Bsmvnk28Ve2l4=.5803fcb1-4614-4c82-86ec-a5c597a821dd@github.com>

On Thu, 6 Nov 2025 16:36:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
> 
> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
> a) to ensure that some sort of reservation size is reported; and
> b) to extract the reserved amount and assert that it is no less than the committed amount
> 
> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).

Yes, for some reason the reserved value is greater than the committed value. We've been speculating that it might be a NMT bug, a CDS thing (which also uses the `mtJavaHeap` NMT tag) or something else.

The approach of checking `reserved >= committed` is a valid approach, but I also think we could just scrap the entire check for the reserved value. The purpose of this test is really to check if the `-XX:+PrintVMInfoAtExit` flag works as intended, which means it should include the NMT summary. Again, if we only care that the NMT summary is printed, we could check for more robust "strings", or just skip checking for an exact reserved value.

Either way, this test has been failing for some time due to the reserved discrepancy so any fix is fine IMO.

test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 61:

> 59:     output_detail.shouldMatch("Java Heap \\(reserved=[0-9]+KB, committed=" + committed_kb + "KB\\)");
> 60:     // Check reserved >= committed.
> 61:     String reserved_kb_string = output_detail.firstMatch("reserved=([0-9]+)KB, committed=" + committed_kb + "KB", 1);

This will likely always match the "Java Heap" line, but should we be more explicit and add "Java Heap" like this?
Suggestion:

    String reserved_kb_string = output_detail.firstMatch("Java Heap \(reserved=([0-9]+)KB, committed=" + committed_kb + "KB\)", 1);

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28179#pullrequestreview-3458228004
PR Review Comment: https://git.openjdk.org/jdk/pull/28179#discussion_r2522180397

From cnorrbin at openjdk.org  Thu Nov 13 09:05:32 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 13 Nov 2025 09:05:32 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <fF1hoR6uoYPtBN7Dy1V6wsoo3N6Yu69Ha_6qEOj9npI=.7a1c0dce-1c66-4a3a-936e-f134a45e7aae@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

LGTM

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

Marked as reviewed by cnorrbin (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3458531316

From phubner at openjdk.org  Thu Nov 13 09:19:08 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 13 Nov 2025 09:19:08 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v21]
In-Reply-To: <2UfkSzuxH68EuDt0x5oY_Hy2Mxm3JT68vwTj9MXZW1w=.1e5c9ca2-bfb3-4ddd-82a7-6164516fd239@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <2UfkSzuxH68EuDt0x5oY_Hy2Mxm3JT68vwTj9MXZW1w=.1e5c9ca2-bfb3-4ddd-82a7-6164516fd239@github.com>
Message-ID: <nBqa9QVbIMINPw1nxLJr899YU7iR0r8BvzmwFgXmMUU=.7028a7b1-de65-404d-ac00-7ff385d68639@github.com>

On Mon, 10 Nov 2025 20:03:35 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improvements.

Thanks again for doing this.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3458594894

From jsjolen at openjdk.org  Thu Nov 13 09:28:26 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 13 Nov 2025 09:28:26 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap
Message-ID: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>

Hi,

This PR wraps the` MallocMemorySummary::_snapshot` in a `DeferredStatic`. This is not strictly necessary as MallocMemorySnapshot does not have a non-trivial constructor, but it does give us more consistency and does act as a safe guard for future changes. 

Testing: GHA

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

Commit messages:
 - Defer static snapshot

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

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

From phubner at openjdk.org  Thu Nov 13 09:37:05 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 13 Nov 2025 09:37:05 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <vubHf5OaEGwMJrk5evTE5iaD-AvyG4Bsmvnk28Ve2l4=.5803fcb1-4614-4c82-86ec-a5c597a821dd@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
 <vubHf5OaEGwMJrk5evTE5iaD-AvyG4Bsmvnk28Ve2l4=.5803fcb1-4614-4c82-86ec-a5c597a821dd@github.com>
Message-ID: <J8MiNfcIzm5SLxX3_f2X90cV7uXJV-SDAKO0TW0sICg=.ea808bf0-640d-4642-afa8-be535be7f42f@github.com>

On Thu, 13 Nov 2025 08:08:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hi all,
>> 
>> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
>> 
>> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
>> a) to ensure that some sort of reservation size is reported; and
>> b) to extract the reserved amount and assert that it is no less than the committed amount
>> 
>> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).
>
> test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 61:
> 
>> 59:     output_detail.shouldMatch("Java Heap \\(reserved=[0-9]+KB, committed=" + committed_kb + "KB\\)");
>> 60:     // Check reserved >= committed.
>> 61:     String reserved_kb_string = output_detail.firstMatch("reserved=([0-9]+)KB, committed=" + committed_kb + "KB", 1);
> 
> This will likely always match the "Java Heap" line, but should we be more explicit and add "Java Heap" like this?
> Suggestion:
> 
>     String reserved_kb_string = output_detail.firstMatch("Java Heap \(reserved=([0-9]+)KB, committed=" + committed_kb + "KB\)", 1);

Good shout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28179#discussion_r2522574951

From syan at openjdk.org  Thu Nov 13 09:37:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 13 Nov 2025 09:37:14 GMT
Subject: RFR: 8371769: TestMemoryInvisibleParent.java fails
 java.nio.file.AccessDeniedException
Message-ID: <zFcxfyZig1unRmDYC7AIRB5KOby3rrp6TAbAkXnp6z8=.6bbd6a2a-60e7-4d08-9e13-aaf8dca7dc43@github.com>

Hi all,

Test test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java fails when run with non-root user. Test will try to write file /sys/fs/cgroup/memory/hidden-parent-TestMemoryInvisibleParent26/memory.limit_in_bytes, and this will make non-root user report java.nio.file.AccessDeniedException. So I think we should skip this test when user is not root.

This PR also add prefix indent for a try block, but do not touch the original logic.

Change has been verified locally on linux-aarch64 with non-root user.

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

Commit messages:
 - 8371769: TestMemoryInvisibleParent.java fails java.nio.file.AccessDeniedException

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

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

From jsikstro at openjdk.org  Thu Nov 13 09:43:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 13 Nov 2025 09:43:47 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v3]
In-Reply-To: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
Message-ID: <1AfMFywOkWMRplle12iyad4OQuufA72Bp9cxYpBb8Mo=.43ed792d-75d8-4a94-b1e0-00b45d037987@github.com>

> Hello,
> 
> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
> 
> Testing:
> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
> * Running through Oracle's tier1-2

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Remove comparison

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28261/files
  - new: https://git.openjdk.org/jdk/pull/28261/files/905e4da0..125b0132

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

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

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

From azafari at openjdk.org  Thu Nov 13 09:47:15 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Nov 2025 09:47:15 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
Message-ID: <FYQiWInZNDDIroBEYwr_XPnKBdJJW6lEoF1kw_WXRDE=.af3ec387-814c-4d88-874e-75b67b9dc40a@github.com>

On Thu, 6 Nov 2025 16:36:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
> 
> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
> a) to ensure that some sort of reservation size is reported; and
> b) to extract the reserved amount and assert that it is no less than the committed amount
> 
> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).

Thanks again for taking this issue.
All good.

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28179#pullrequestreview-3458755811

From sgehwolf at openjdk.org  Thu Nov 13 10:05:25 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 13 Nov 2025 10:05:25 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <ho9I83ItEzD8807dKyFokWhJFoTGNAYL-iERqgO35lo=.2d687123-8174-4d01-a3f3-271e8b31b70e@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Thanks for the review. I still need a review from a Reviewer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28157#issuecomment-3526909866

From phubner at openjdk.org  Thu Nov 13 12:02:56 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 13 Nov 2025 12:02:56 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory [v2]
In-Reply-To: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
Message-ID: <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>

> Hi all,
> 
> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
> 
> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
> a) to ensure that some sort of reservation size is reported; and
> b) to extract the reserved amount and assert that it is no less than the committed amount
> 
> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).

Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Review suggestion.
 - Merge branch 'master' into JDK-8371320
 - Use regular expression based matching instead.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28179/files
  - new: https://git.openjdk.org/jdk/pull/28179/files/cf71e104..95ee671c

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

  Stats: 169300 lines in 969 files changed: 114699 ins; 26184 del; 28417 mod
  Patch: https://git.openjdk.org/jdk/pull/28179.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28179/head:pull/28179

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

From phubner at openjdk.org  Thu Nov 13 12:02:59 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 13 Nov 2025 12:02:59 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
Message-ID: <7vY4WsbRpm9o2Qvs27BUEKRAdUHP7BVmwXYPL99v5As=.a561db58-abc0-42bf-8915-79ab48b4dccc@github.com>

On Thu, 6 Nov 2025 16:36:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
> 
> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
> a) to ensure that some sort of reservation size is reported; and
> b) to extract the reserved amount and assert that it is no less than the committed amount
> 
> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).

Thanks for the feedback! 

I've merged in changes and applied your comment, @jsikstro. @afshin-zafari we already check that we commit 64 MB via the regular expression, so I don't think it is necessary to add another numeric check. I've ran it through tier1 testing and it's clean. I'll require re-reviews though. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28179#issuecomment-3527480689

From jsikstro at openjdk.org  Thu Nov 13 12:44:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 13 Nov 2025 12:44:53 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory [v2]
In-Reply-To: <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
 <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
Message-ID: <7Td9B1ww0IeUwtAlQl1Lyn9dDdqQGbisHqwBrg2GY3I=.568f63c6-508d-45a7-85dd-001729842b9d@github.com>

On Thu, 13 Nov 2025 12:02:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
>> 
>> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
>> a) to ensure that some sort of reservation size is reported; and
>> b) to extract the reserved amount and assert that it is no less than the committed amount
>> 
>> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Review suggestion.
>  - Merge branch 'master' into JDK-8371320
>  - Use regular expression based matching instead.

Marked as reviewed by jsikstro (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28179#pullrequestreview-3459612321

From jsjolen at openjdk.org  Thu Nov 13 12:52:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 13 Nov 2025 12:52:22 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap
Message-ID: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>

Hi,

We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.

Testing: GHA

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

Commit messages:
 - Replace MemTagBitMap with BitMap

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

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

From azafari at openjdk.org  Thu Nov 13 13:24:28 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Nov 2025 13:24:28 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v2]
In-Reply-To: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
Message-ID: <_AofZ8PbSikoVuxS2b_NyTLK_dkvnRhlQgfVnRLggnk=.e779a912-0de5-4a21-9ee3-8b1954b32033@github.com>

> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
> 
> The fix is to skip cases where page-number under checking is `-1`.
> Tested under UBSAN build.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  more descriptive

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28151/files
  - new: https://git.openjdk.org/jdk/pull/28151/files/5afdca2a..d45208dc

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

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

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

From azafari at openjdk.org  Thu Nov 13 13:34:55 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Nov 2025 13:34:55 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v3]
In-Reply-To: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
Message-ID: <A4fiZvDDgOCScjWFK8qzwwLeJPB1igIFrhBuvHyKwCQ=.c07a59a7-b1f7-42a8-9e74-61142827c2c7@github.com>

> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
> 
> The fix is to skip cases where page-number under checking is `-1`.
> Tested under UBSAN build.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  better comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28151/files
  - new: https://git.openjdk.org/jdk/pull/28151/files/d45208dc..f3f3fe0e

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

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

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

From jsikstro at openjdk.org  Thu Nov 13 13:38:16 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 13 Nov 2025 13:38:16 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v4]
In-Reply-To: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
Message-ID: <42Sg6OGmRQDrzLynJP5mkLYgV6UxDsJW34kjRpI8bpY=.d23a23ed-fa62-496c-8a5c-70248dcff572@github.com>

> Hello,
> 
> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
> 
> Testing:
> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
> * Running through Oracle's tier1-2

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Harden comment around user configuration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28261/files
  - new: https://git.openjdk.org/jdk/pull/28261/files/125b0132..26765e87

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

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

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

From ayang at openjdk.org  Thu Nov 13 13:49:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 13 Nov 2025 13:49:04 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v3]
In-Reply-To: <1AfMFywOkWMRplle12iyad4OQuufA72Bp9cxYpBb8Mo=.43ed792d-75d8-4a94-b1e0-00b45d037987@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <1AfMFywOkWMRplle12iyad4OQuufA72Bp9cxYpBb8Mo=.43ed792d-75d8-4a94-b1e0-00b45d037987@github.com>
Message-ID: <SiZPx54oo55IpOPpcsfUM7IYkZYZleUag1-CfWGdIcM=.f3d38c6e-3dd6-41f4-8bca-1138eaa01b74@github.com>

On Thu, 13 Nov 2025 09:43:47 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
>> 
>> Testing:
>> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
>> * Running through Oracle's tier1-2
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove comparison

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28261#pullrequestreview-3459873416

From jsjolen at openjdk.org  Thu Nov 13 14:36:31 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 13 Nov 2025 14:36:31 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v3]
In-Reply-To: <A4fiZvDDgOCScjWFK8qzwwLeJPB1igIFrhBuvHyKwCQ=.c07a59a7-b1f7-42a8-9e74-61142827c2c7@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
 <A4fiZvDDgOCScjWFK8qzwwLeJPB1igIFrhBuvHyKwCQ=.c07a59a7-b1f7-42a8-9e74-61142827c2c7@github.com>
Message-ID: <RM4TfiwmshU5z8VKfPUGZO-OR2vwQHFDFoRVAYHSNDE=.0e7157bc-b859-48b1-9d78-521f1c1eb98e@github.com>

On Thu, 13 Nov 2025 13:34:55 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
>> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
>> 
>> The fix is to skip cases where page-number under checking is `-1`.
>> Tested under UBSAN build.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   better comment

Marked as reviewed by jsjolen (Reviewer).

test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 88:

> 86:   static constexpr int PAGE_CONTAINED_IN_RANGE_TAG = -1;
> 87:   static constexpr bool IS_PAGE_CONTAINED_IN_COMMITTED_REGION(int a) { return (a == PAGE_CONTAINED_IN_RANGE_TAG); }
> 88:   static constexpr void SET_PAGE_AS_CONTAINED_IN_COMMITTED_REGION(int &a) { a = PAGE_CONTAINED_IN_RANGE_TAG; }

The functions aren't `constexpr`, so you can skip those. I think all of these can be in `this_style_of_naming` instead.

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

PR Review: https://git.openjdk.org/jdk/pull/28151#pullrequestreview-3460097474
PR Review Comment: https://git.openjdk.org/jdk/pull/28151#discussion_r2523708175

From azafari at openjdk.org  Thu Nov 13 15:31:52 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Nov 2025 15:31:52 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v4]
In-Reply-To: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
Message-ID: <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>

> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
> 
> The fix is to skip cases where page-number under checking is `-1`.
> Tested under UBSAN build.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  style and not constexpr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28151/files
  - new: https://git.openjdk.org/jdk/pull/28151/files/f3f3fe0e..84a1e3c8

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

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

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

From azafari at openjdk.org  Thu Nov 13 15:34:53 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 13 Nov 2025 15:34:53 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory [v2]
In-Reply-To: <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
 <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
Message-ID: <2xqe0lDBcnJJHK0uGClab2lxqWf0SA8UWMfJjPFDk8M=.89730fcb-7b0e-4f2d-bd2a-0072047c4690@github.com>

On Thu, 13 Nov 2025 12:02:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
>> 
>> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
>> a) to ensure that some sort of reservation size is reported; and
>> b) to extract the reserved amount and assert that it is no less than the committed amount
>> 
>> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Review suggestion.
>  - Merge branch 'master' into JDK-8371320
>  - Use regular expression based matching instead.

Still good. Thanks.

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28179#pullrequestreview-3460370637

From phubner at openjdk.org  Thu Nov 13 15:43:06 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 13 Nov 2025 15:43:06 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory [v2]
In-Reply-To: <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
 <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
Message-ID: <QZiPO609hMTS4q4upUx3yXg7MVGnyhquaC3nWAA99iw=.2414b4a8-88d1-479b-bf51-f88ffa15cec6@github.com>

On Thu, 13 Nov 2025 12:02:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
>> 
>> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
>> a) to ensure that some sort of reservation size is reported; and
>> b) to extract the reserved amount and assert that it is no less than the committed amount
>> 
>> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Review suggestion.
>  - Merge branch 'master' into JDK-8371320
>  - Use regular expression based matching instead.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28179#issuecomment-3528400175

From duke at openjdk.org  Thu Nov 13 15:43:07 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Nov 2025 15:43:07 GMT
Subject: RFR: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory [v2]
In-Reply-To: <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
 <tUzgZYiGEQPepjtozqRiD7s8VrEEONfwhJRmAyYLRDg=.3b179646-f556-47e5-b078-5cac0b7f0182@github.com>
Message-ID: <suK0ENm3OT8Egq6soEBII5a6ne_RmHU_bY_yPCFl3_U=.56c56bba-f981-4da6-8c9a-88458efb6ece@github.com>

On Thu, 13 Nov 2025 12:02:56 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
>> 
>> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
>> a) to ensure that some sort of reservation size is reported; and
>> b) to extract the reserved amount and assert that it is no less than the committed amount
>> 
>> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).
>
> Paul H?bner has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Review suggestion.
>  - Merge branch 'master' into JDK-8371320
>  - Use regular expression based matching instead.

@Arraying 
Your change (at version 95ee671c66d212f8b46e5bbcc3f711c106cffac9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28179#issuecomment-3528405285

From lmesnik at openjdk.org  Thu Nov 13 16:23:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Nov 2025 16:23:43 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <gKV9TIOUce_DKfwYB8-NOBT9dpTicD1cvTgHbDFv1IM=.7d75578d-96fe-4879-9041-6a3994b9f0c4@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3460609576

From macarte at openjdk.org  Thu Nov 13 17:57:04 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 17:57:04 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v2]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <AMbILLeAEkXIC83WjxrMvX2yFHFDPriJWN70I_Bh0nE=.c1f1f6eb-c41f-4493-9d45-56b04745c1ba@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/2f09c157..7b7e2f7e

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

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

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

From pchilanomate at openjdk.org  Thu Nov 13 19:20:36 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 19:20:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
Message-ID: <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>

On Wed, 12 Nov 2025 19:07:49 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 388:
> 
>> 386:                 try {
>> 387:                     Thread.sleep(1000);
>> 388:                 } catch(Exception e) {}
> 
> Why is this 1 second delay needed?

We need to give time for the resumer thread to block on the `threadLock` before we release it. We could reduce the amount of sleep time though.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:
> 
>> 426:             // launch the waiter thread
>> 427:             synchronized (barrierLaunch) {
>> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);
> 
> This change to `wait` for `1` instead of `0` requires this comment to be updated from:
> 
>                 // TS_READY_TO_NOTIFY is set after the main thread has
>                 // entered threadLock so a spurious wakeup can't get the
>                 // waiter thread out of this threadLock.wait(0) call:
> 
> to:
> 
>                 // TS_READY_TO_NOTIFY is set after the main thread has
>                 // entered threadLock so a spurious wakeup can't get the
>                 // waiter thread out of this threadLock.wait(0) call in
>                 // doWork1 or doWork2. doWork3 passes a one so that the
>                 // wait() can terminate early and block on reentry.
> 
> 
> I'm having trouble seeing why this third test case is necessary. We do a short `wait(1)`
> in this test case instead of a `wait(0)` so we terminate the `wait(1)` with a timeout instead
> of a `notify()` from the main thread. 
> 
> In all worker test cases, the main thread grabs the threadsLock when the "waiter" thread
> calls `wait()`, the main thread does a `notify()`, the main thread waits until the worker
> thread contends on threadsLock and finally the main thread suspends the worker thread.
> The only thing that I see that the `wait(1)` brings to the party is that the worker3 thread
> might get to re-entry block on threadsLock via a timeout instead of a notify.
> 
> What am I missing here?

The `notify()` call doesn?t unpark the waiter thread, it just moves it from the `_wait_set` to the `_entry_list`. The wait(timeout) is there to allow it to run again so that it is suspended in `reenter_internal()`. But currently the timings will not exercise this case well. I added some comments to fix it.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 454:
> 
>> 452:             try {
>> 453:                 Thread.sleep(1000);
>> 454:             } catch(Exception e) {}
> 
> Why is this 1 second delay needed?

This sleep is not needed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 509:
> 
>> 507:                 try {
>> 508:                     Thread.sleep(1000);
>> 509:                 } catch(Exception e) {}
> 
> Why is this 1 second delay needed?

Same here, we need to give time for the resumer thread to block on the threadLock before we release it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524648214
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524652123
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524641301
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524648857

From pchilanomate at openjdk.org  Thu Nov 13 19:20:39 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 19:20:39 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <B2pu1K767Mx5pPslzgv4i03cpeC3hmtSlzTquOvcJ6o=.f04ea9be-b689-441b-9a43-8905f138dba6@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:

> 426:             // launch the waiter thread
> 427:             synchronized (barrierLaunch) {
> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);

We should increase this timeout to minimize the chance of it happening between the main thread acquiring the `threadLock` and issuing the notification, in which case the waiter will not go through `reenter_internal` but through `enter`. Also it avoids some funny scheduling where the main thread never acquires the `threadLock`.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 466:

> 464:                 testState = TS_READY_TO_NOTIFY;
> 465:                 threadLock.notify();
> 466: 

We should add a `Thread.sleep` here to give time for the wait to timeout before suspending the waiter thread. Should be more than what the waiter thread is using as timeout. I have tested a timeout value of 100ms and here sleeping 200ms and always see the deadlock on `reenter_internal` (with current mainline code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524640318
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524643382

From pchilanomate at openjdk.org  Thu Nov 13 19:23:46 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 19:23:46 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 31:

> 29:  * @library /test/lib
> 30:  * @compile SuspendWithObjectMonitorWait.java
> 31:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 1

Note that these passed values are overriding timeMax.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524657555

From macarte at openjdk.org  Thu Nov 13 19:41:40 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 13 Nov 2025 19:41:40 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Document use of DiagnosticCommand

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/7b7e2f7e..cdd1f1d4

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

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

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

From dcubed at openjdk.org  Thu Nov 13 20:35:28 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:35:28 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <VI_4cDAV4pRYjj58cxRqFyjG51UR5ifE_5JW6bhqVOY=.98296ac3-9ca1-4976-864c-bf0714b83f1d@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

The transaction diagram in SuspendWithObjectMonitorWait.java on L56 -> L77 is
for the `doWork1` test so the comment should be modifed to make that clear by
adding this above L56:

//
// doWork1 algorithm:

I've created a transaction diagram for doWork2:

//
// doWork2 algorithm:
//
// main               waiter              resumer
// =================  ==================  ===================
// launch waiter
// <launch returns>   waiter running
// launch resumer     enter threadLock
// <launch returns>   threadLock.wait()   resumer running
// enter threadLock   :                   wait for notify
// threadLock.notify  wait finishes       :
// :                  reenter blocks      :
// suspend waiter     <suspended>         :
// <ready to test>    :                   :
// :                  :                   :
// notify resumer     :                   wait finishes
// delay 1-second     :                   :
// exit threadLock    :                   :
// join resumer       :                   enter threadLock
// :                  <resumed>           resume waiter
// :                  :                   exit threadLock
// :                  reenter threadLock  :
// <join returns>     :                   resumer exits
// join waiter        :
// <join returns>     waiter exits
//
// Note: The sleep(1-second) in main along with the delayed exit
//       of threadLock in main forces the resumer thread to reach
//       "enter threadLock" and block. This difference from doWork1
//       forces the resumer thread to be contending for threadLock
//       while the waiter thread is in threadLock.wait() increasing
//       stress on the monitor sub-system.
//

I've created a transaction diagram for doWork3:

//
// doWork3 algorithm:
//
// main                 waiter                  resumer
// ===================  ======================  ===================
// launch waiter
// <launch returns>     waiter running
// launch resumer       enter threadLock
// <launch returns>     while !READY_TO_NOTIFY  resumer running
// delay 1-second         threadLock.wait(1)    wait for notify
// enter threadLock     :                       :
// set READY_TO_NOTIFY  :
// threadLock.notify    wait finishes           :
// :                    reenter blocks          :
// suspend waiter       <suspended>             :
// <ready to test>      :                       :
// :                    :                       :
// notify resumer       :                       wait finishes
// delay 1-second       :                       :
// exit threadLock      :                       :
// join resumer         :                       enter threadLock
// :                    <resumed>               resume waiter
// :                    :                       exit threadLock
// :                    reenter threadLock      :
// <join returns>       :                       resumer exits
// join waiter          :
// <join returns>       waiter exits
//
// Note: The sleep(1-second) in main along with the delayed exit
//       of threadLock in main forces the resumer thread to reach
//       "enter threadLock" and block. This difference from doWork1
//       forces the resumer thread to be contending for threadLock
//       while the waiter thread is in the threadLock.wait(1) tight
//       loop increasing stress on the monitor sub-system.
//
// Note: The first sleep(1-second) in main and the wait(1) in the waiter
//       thread allows the waiter thread to loop tightly here:
//         while !READY_TO_NOTIFY
//           threadLock.wait(1)
//

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529595262
PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529599987
PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529602353

From dcubed at openjdk.org  Thu Nov 13 20:46:49 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:49 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <LAqs9AH7Qt69n4QxE39tlrKQCHRDEU6kfWue98Pj_t0=.3f16c76d-d14d-4229-bfe9-431b29805d18@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

Marked as reviewed by dcubed (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 110:

> 108: 
> 109:     public static void main(String[] args) throws Exception {
> 110:         int test = Integer.parseInt(args[0]);

I think this will throw if the test is called without any parameters.

Also, the `usage` function needs to be updated to reflect the addition of the
test number parameter.

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3461580809
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524858587

From dcubed at openjdk.org  Thu Nov 13 20:46:52 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:52 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>
Message-ID: <dixtIsBamOGvMeZR4FXJlv4O6DVoaXbW9tTSv2BHjow=.17ee7cff-0729-49fa-8735-e9f1b4297b4c@github.com>

On Thu, 13 Nov 2025 19:20:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 31:
> 
>> 29:  * @library /test/lib
>> 30:  * @compile SuspendWithObjectMonitorWait.java
>> 31:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 1
> 
> Note that these passed values are overriding timeMax.

The addition of the test number should have been done as a required parameter.
That would push the optional timeMax parameter to be the optional second parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524856106

From dcubed at openjdk.org  Thu Nov 13 20:46:54 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:54 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>
Message-ID: <TYLevWiK7oXdTDwG-dmB4De8iwR9pQr_EEPbsu0MXCQ=.e4743b79-9874-4abd-8a9e-38cf6b6d534b@github.com>

On Wed, 12 Nov 2025 20:04:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 372:
>> 
>>> 370:                 // - a threadLock enter in the resumer thread
>>> 371:                 // - resumption of the waiter thread
>>> 372:                 // - a threadLock enter in the freshly resumed waiter thread
>> 
>> This list of step tests is identical to the list on L490 -> L493 and the
>> original llist on L256 -> L259.
>> 
>> This step comment:
>> `370:               // - a threadLock enter in the resumer thread`
>> should be updated to something like:
>> 
>>              // - a blocked threadLock enter in the resumer thread while the
>>              //   threadLock is held by the main thread.
>> 
>> 
>> This change of threadLock scope also requires this update from:
>> 
>> 605:        // - tries to grab the threadLock (should not block!)
>> 
>> 
>> to:
>> 
>> 605:        // - tries to grab the threadLock (should not block with doWork1!)
>
> I can't figure out why we're delaying the resumer thread in `doWork2`.

Update: I figured this out. See the new doWork2 transaction diagram.

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 493:
>> 
>>> 491:                 // - a threadLock enter in the resumer thread
>>> 492:                 // - resumption of the waiter thread
>>> 493:                 // - a threadLock enter in the freshly resumed waiter thread
>> 
>> This list of step tests is identical to the list on L369 -> L372 and the
>> original llist on L256 -> L259.
>> 
>> This step comment:
>> 
>> 491:               // - a threadLock enter in the resumer thread
>> 
>> should be updated to something like:
>> 
>>              // - a blocked threadLock enter in the resumer thread while the
>>              //   threadLock is held by the main thread.
>
> I can't figure out why we're delaying the resumer thread in `doWork3`.

Update: I figured this out. See the new doWork3 transaction diagram.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524860241
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524872816

From dcubed at openjdk.org  Thu Nov 13 20:46:58 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:46:58 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>
Message-ID: <O4k-l4EhvJP0d-ixsj-QLSvjRcXcBNEyhKhk88OqXug=.7bbc2991-088d-48fd-9afe-a3c5fc0fbca1@github.com>

On Thu, 13 Nov 2025 19:16:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 388:
>> 
>>> 386:                 try {
>>> 387:                     Thread.sleep(1000);
>>> 388:                 } catch(Exception e) {}
>> 
>> Why is this 1 second delay needed?
>
> We need to give time for the resumer thread to block on the `threadLock` before we release it. We could reduce the amount of sleep time though.

Agreed. I pretty much said the same thing about the resumer thread in the new doWork2 transaction
diagram (and the new doWork3 transaction diagram).

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:
>> 
>>> 426:             // launch the waiter thread
>>> 427:             synchronized (barrierLaunch) {
>>> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);
>> 
>> This change to `wait` for `1` instead of `0` requires this comment to be updated from:
>> 
>>                 // TS_READY_TO_NOTIFY is set after the main thread has
>>                 // entered threadLock so a spurious wakeup can't get the
>>                 // waiter thread out of this threadLock.wait(0) call:
>> 
>> to:
>> 
>>                 // TS_READY_TO_NOTIFY is set after the main thread has
>>                 // entered threadLock so a spurious wakeup can't get the
>>                 // waiter thread out of this threadLock.wait(0) call in
>>                 // doWork1 or doWork2. doWork3 passes a one so that the
>>                 // wait() can terminate early and block on reentry.
>> 
>> 
>> I'm having trouble seeing why this third test case is necessary. We do a short `wait(1)`
>> in this test case instead of a `wait(0)` so we terminate the `wait(1)` with a timeout instead
>> of a `notify()` from the main thread. 
>> 
>> In all worker test cases, the main thread grabs the threadsLock when the "waiter" thread
>> calls `wait()`, the main thread does a `notify()`, the main thread waits until the worker
>> thread contends on threadsLock and finally the main thread suspends the worker thread.
>> The only thing that I see that the `wait(1)` brings to the party is that the worker3 thread
>> might get to re-entry block on threadsLock via a timeout instead of a notify.
>> 
>> What am I missing here?
>
> The `notify()` call doesn?t unpark the waiter thread, it just moves it from the `_wait_set` to the `_entry_list`. The wait(timeout) is there to allow it to run again so that it is suspended in `reenter_internal()`. But currently the timings will not exercise this case well. I added some comments to fix it.

Please see the notes in the new doWork3 transaction diagram. I think I've covered this case.

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 454:
>> 
>>> 452:             try {
>>> 453:                 Thread.sleep(1000);
>>> 454:             } catch(Exception e) {}
>> 
>> Why is this 1 second delay needed?
>
> This sleep is not needed.

I have a comment about this in the new doWork3 transaction diagram.

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 509:
>> 
>>> 507:                 try {
>>> 508:                     Thread.sleep(1000);
>>> 509:                 } catch(Exception e) {}
>> 
>> Why is this 1 second delay needed?
>
> Same here, we need to give time for the resumer thread to block on the threadLock before we release it.

Agreed. I pretty much said the same thing about the resumer thread in the new doWork3 transaction
diagram (and the new doWork2 transaction diagram).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524862590
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524866785
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524870502
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2524875174

From dcubed at openjdk.org  Thu Nov 13 20:54:16 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 13 Nov 2025 20:54:16 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
Message-ID: <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>

On Wed, 12 Nov 2025 13:29:07 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
>> 
>> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Removed incorrect assert,
>  - 8366659: Fixed merge conflict
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6

So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java.

I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended
thread made the successor over and over again so that none of the other contending threads
ever get the monitor even though it is unlocked.

I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread
manages to re-enter the monitor and then gets suspended while on its way back to Java.

@toxaart and/or @pchilano - Please verify my understanding of this mapping from the two
new test cases to the two deadlocks. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529662045

From coleenp at openjdk.org  Thu Nov 13 21:34:17 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 13 Nov 2025 21:34:17 GMT
Subject: RFR: 8371860: Make non-pubic methods in java_lang_Class private
Message-ID: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>

Please review this small cleanup for method declarations in java_lang_Class.
Testing with tier1-4.

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

Commit messages:
 - 8371860: Make non-pubic methods in java_lang_Class private

Changes: https://git.openjdk.org/jdk/pull/28308/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28308&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371860
  Stats: 25 lines in 2 files changed: 6 ins; 18 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28308.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28308/head:pull/28308

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

From kbarrett at openjdk.org  Thu Nov 13 21:46:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 13 Nov 2025 21:46:02 GMT
Subject: RFR: 8371860: Make non-pubic methods in java_lang_Class private
In-Reply-To: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
References: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
Message-ID: <Jkx1ytE4txcw55u7hHm1_Dlst7jz9yLPk9iwrrWxFRA=.d6cbcfc1-ce04-4692-988e-8a0a65219afd@github.com>

On Thu, 13 Nov 2025 21:26:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this small cleanup for method declarations in java_lang_Class.
> Testing with tier1-4.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28308#pullrequestreview-3461808902

From pchilanomate at openjdk.org  Thu Nov 13 21:49:46 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 13 Nov 2025 21:49:46 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
Message-ID: <dW3uMNCyE3EqA3DTAQ7IVaKfhviQd1Q_kzCmglAAVvI=.464e99d1-6917-4a0f-98f0-9d7afa5aa080@github.com>

On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java.
> 
> I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended thread made the successor over and over again so that none of the other contending threads ever get the monitor even though it is unlocked.
> 
> I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread manages to re-enter the monitor and then gets suspended while on its way back to Java.
> 
> @toxaart and/or @pchilano - Please verify my understanding of this mapping from the two new test cases to the two deadlocks. Thanks!
>
The PR description of the cases isn?t quite accurate. The explanation in `1.` applies to both deadlocks, the only difference is where the successor could be suspended:
[1]  https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897 (exercised by doWork2)
[2]  https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149 (exercised by doWork3)

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3529846713

From duke at openjdk.org  Fri Nov 14 03:27:54 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 14 Nov 2025 03:27:54 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v11]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <hH4tnCcXQYsqpqOsA63rWxpcL5rqPzUkrUeBKCie8kk=.1c9baa65-bc61-47ea-b8e3-e6e916f6abf9@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  address feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/83f63ce5..1583a684

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

  Stats: 23 lines in 4 files changed: 14 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Fri Nov 14 03:36:45 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 14 Nov 2025 03:36:45 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v12]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <BIWQXXXV1UbvhJe9H4nSMnfMs6mb3uTvksyo_1xE58s=.d5052187-ad48-43a7-aecb-00cc80032026@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  address feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/1583a684..70c5c644

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

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

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

From duke at openjdk.org  Fri Nov 14 03:49:48 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 14 Nov 2025 03:49:48 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v13]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <H5VXB0bpL1Y9Ez8FtdiPQkGLUrlaJsLz_jC9LdTTK7o=.72b2e2da-ec97-48d1-a8be-86aa7c5cae05@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  more cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/70c5c644..e09e98b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=11-12

  Stats: 5 lines in 3 files changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Fri Nov 14 04:35:30 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 14 Nov 2025 04:35:30 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v14]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <GsmkboKFP9fHQIbpD0oDz_B8iy1YzkhoVkSxDWzvcSg=.d00229ee-715c-476b-973e-db51b036e44f@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  more simplifications

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/e09e98b6..99023e9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=12-13

  Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27868.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27868/head:pull/27868

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

From duke at openjdk.org  Fri Nov 14 04:38:43 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Fri, 14 Nov 2025 04:38:43 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v15]
In-Reply-To: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
Message-ID: <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>

> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs

Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27868/files
  - new: https://git.openjdk.org/jdk/pull/27868/files/99023e9b..572da29f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27868&range=13-14

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

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

From iklam at openjdk.org  Fri Nov 14 04:50:34 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Nov 2025 04:50:34 GMT
Subject: RFR: 8371874: AOTLinkedClassBulkLoader::preload_classes() should not
 allocate heap objects
Message-ID: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>

`AOTLinkedClassBulkLoader::preload_classes()` indirectly calls `java_lang_Class::restore_archived_mirror()` which can allocate an `int` array for the `init_lock`. However, the `init_lock` has already been allocated during AOT cache assembly :


java_lang_Class::create_scratch_mirror()
-> allocate_mirror()
  -> initialize_mirror_fields()
    -> set_init_lock()


So there's no need to allocate it again in the production run.

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

Commit messages:
 - 8371874: AOTLinkedClassBulkLoader::preload_classes() should not allocate heap objects

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

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

From stefank at openjdk.org  Fri Nov 14 06:54:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 14 Nov 2025 06:54:03 GMT
Subject: RFR: 8371860: Make non-pubic methods in java_lang_Class private
In-Reply-To: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
References: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
Message-ID: <-VOLdVL0Pzm8McJNIuNLMykOjh3ufb6cYrgmOV1tMSA=.4edaa18d-3c1e-409d-beb2-e0c795cb4afa@github.com>

On Thu, 13 Nov 2025 21:26:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this small cleanup for method declarations in java_lang_Class.
> Testing with tier1-4.

You might want to change the title ...

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

PR Comment: https://git.openjdk.org/jdk/pull/28308#issuecomment-3531171116

From iklam at openjdk.org  Fri Nov 14 07:04:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Nov 2025 07:04:09 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v2]
In-Reply-To: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
Message-ID: <g33oxbvt2FPJNOhucDUVJKjFdNDrawHDDTyV_pSsw5I=.f9ab5a41-2a73-4923-933a-95e9cdaf90d9@github.com>

> **Overview**
> 
> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
> 
> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
> 
> **The fix**
> 
> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
> 
> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
> 
> Please see comments in the above two functions for more details.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - clean up of old C++ class name ArchiveHeapWriter
 - @ashu-mehra comment -- simplified the criteria for _is_writing_deterministic_heap
 - Merge branch 'master' into 8363986-heap-region-in-aot-cache-not-determinitic-address
 - More clean up
 - fixed aot map
 - clean up
 - 8363986: Heap region in CDS archive is not at deterministic address

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

Changes: https://git.openjdk.org/jdk/pull/28052/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28052&range=01
  Stats: 141 lines in 7 files changed: 100 ins; 17 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/28052.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28052/head:pull/28052

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

From iklam at openjdk.org  Fri Nov 14 07:07:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Nov 2025 07:07:08 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v2]
In-Reply-To: <hAxa0KkLgtQeMNybVP8U-SVF3zMlkvv7ooINvgiHArw=.6b46060d-ac01-4505-b9c9-872385c8209d@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <hAxa0KkLgtQeMNybVP8U-SVF3zMlkvv7ooINvgiHArw=.6b46060d-ac01-4505-b9c9-872385c8209d@github.com>
Message-ID: <WQN17R0u43zvl05RzI0OJJ4GmegzOz66zPoCdNDEBXI=.8e29c573-47f0-46be-b451-64c761dc93e5@github.com>

On Wed, 5 Nov 2025 22:55:25 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - clean up of old C++ class name ArchiveHeapWriter
>>  - @ashu-mehra comment -- simplified the criteria for _is_writing_deterministic_heap
>>  - Merge branch 'master' into 8363986-heap-region-in-aot-cache-not-determinitic-address
>>  - More clean up
>>  - fixed aot map
>>  - clean up
>>  - 8363986: Heap region in CDS archive is not at deterministic address
>
> src/hotspot/share/cds/archiveHeapWriter.cpp line 96:
> 
>> 94:     guarantee(MIN_GC_REGION_ALIGNMENT <= G1HeapRegion::min_region_size_in_words() * HeapWordSize, "must be");
>> 95: 
>> 96:     if (CDSConfig::old_cds_flags_used() && !CDSConfig::is_dumping_aot_linked_classes() && UseG1GC) {
> 
> Wouldn't it be better to add a VM command line flag to indicate that deterministic dump is needed, and use that flag in `Images.gmk`, instead of relying on these conditions?

Since determinism is required only for the old CDS workflow, which will probably be deprecated soon, I think we should avoid adding new VM flags.

I have updated the code to use  always set `_is_writing_deterministic_heap = true` when using the old CDS workflow. This avoid coupling with the makefiles, and should have minimal impact with the users of old CDS archives. In some cases, runtime relocation might always happen (e.g., G1 with large heaps), but the cost of relocation is usually small (less than 1ms).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28052#discussion_r2526047723

From shade at openjdk.org  Fri Nov 14 07:35:06 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 14 Nov 2025 07:35:06 GMT
Subject: RFR: 8371874: AOTLinkedClassBulkLoader::preload_classes() should
 not allocate heap objects
In-Reply-To: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>
References: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>
Message-ID: <Z0sxDfnZFtYi4s5CvMBYp8NREkv7CrK742i6mFGiQp0=.7e67dcbb-6406-47c5-8202-84df84b7211c@github.com>

On Fri, 14 Nov 2025 04:43:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `AOTLinkedClassBulkLoader::preload_classes()` indirectly calls `java_lang_Class::restore_archived_mirror()` which can allocate an `int` array for the `init_lock`. However, the `init_lock` has already been allocated during AOT cache assembly :
> 
> 
> java_lang_Class::create_scratch_mirror()
> -> allocate_mirror()
>   -> initialize_mirror_fields()
>     -> set_init_lock()
> 
> 
> So there's no need to allocate it again in the production run.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28315#pullrequestreview-3463270588

From jsjolen at openjdk.org  Fri Nov 14 07:52:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 07:52:08 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v4]
In-Reply-To: <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
 <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
Message-ID: <ADJK9A76_qVr0TDa8un-ayAXFNvlU9sS8FSx1dJiAwM=.33adbcae-ddc0-42f7-b8c8-66444b42572e@github.com>

On Thu, 13 Nov 2025 15:31:52 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
>> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
>> 
>> The fix is to skip cases where page-number under checking is `-1`.
>> Tested under UBSAN build.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style and not constexpr

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28151#pullrequestreview-3463374822

From phubner at openjdk.org  Fri Nov 14 08:16:17 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 14 Nov 2025 08:16:17 GMT
Subject: RFR: 8371607: Remove GCSharedStringsDuringDumpWb.java after
 JDK-8362561
Message-ID: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>

Hi all,

[JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) removed `runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java` which was the only place where `GCSharedStringsDuringDumpWb.java` was used. Therefore, `GCSharedStringsDuringDumpWb.java` should be cleaned up.

Testing: tiers 1-3 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

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

Commit messages:
 - Remove class.

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

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

From phubner at openjdk.org  Fri Nov 14 08:25:20 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 14 Nov 2025 08:25:20 GMT
Subject: RFR: 8371778: Make MallocMemorySummary::_snapshot a DeferredStatic
In-Reply-To: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
References: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
Message-ID: <PZl1cGG0ZIaXWA5crI6cEFhZLXdkGltFSPyZbeAuM7E=.ec6e67f9-4f2b-450d-9f47-df5530bd28a2@github.com>

On Wed, 12 Nov 2025 07:48:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR wraps the` MallocMemorySummary::_snapshot` in a `DeferredStatic`. This is not strictly necessary as MallocMemorySnapshot does not have a non-trivial constructor, but it does give us more consistency and does act as a safe guard for future changes. 
> 
> Testing: GHA

Looks good, thanks.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/28257#pullrequestreview-3463579387

From phubner at openjdk.org  Fri Nov 14 08:31:09 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 14 Nov 2025 08:31:09 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v4]
In-Reply-To: <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
 <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
Message-ID: <vR59j8XpHzMbie2imbHan4NGSDLcCGVKt-hg0OJlUNg=.6ffd40ec-edae-4b7e-b9fb-e45deefd56ef@github.com>

On Thu, 13 Nov 2025 15:31:52 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
>> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
>> 
>> The fix is to skip cases where page-number under checking is `-1`.
>> Tested under UBSAN build.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style and not constexpr

test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 97:

> 95:         continue;
> 96:       }
> 97:       address page_addr = base + page_num[index] * page_sz;

What if we `assert(page_num[index] >= 0)` at this point if we know that negative numbers may cause overflows?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28151#discussion_r2526444037

From phubner at openjdk.org  Fri Nov 14 08:33:30 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 14 Nov 2025 08:33:30 GMT
Subject: Integrated: 8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java
 fails with unexpected amount for Java Heap reserved memory
In-Reply-To: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
References: <nNvq_kb2GwJPKLY9xA8LFtqlmlz4cLlKV287gN2oI5g=.f2f44d30-212f-47d0-8de0-019ecaada09c@github.com>
Message-ID: <i_zj4WEmtz1h5pzEdc-W6KnmAdUXtiAs3n5XtYWys-g=.c2d6ff47-2435-4cb0-aa10-68c437ed098e@github.com>

On Thu, 6 Nov 2025 16:36:33 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> In [JDK-8364741](https://bugs.openjdk.org/browse/JDK-8364741) it was discovered that asan reserves a bit more heap. The test got patched by checking for asan and adjusting the expectation, respectively.
> 
> It turns out that, rarely, we do reserve more memory even without asan enabled. This change updates the test:
> a) to ensure that some sort of reservation size is reported; and
> b) to extract the reserved amount and assert that it is no less than the committed amount
> 
> Testing: Ran tier1. Stress tested the individual test with 5x100 repetitions per platform (Linux x64, AArch64; macOS x64, AArch64; Windows x64).

This pull request has now been integrated.

Changeset: 81e0c87f
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81e0c87f28934cb0d66ad2500352b2728f44a1b7
Stats:     14 lines in 1 file changed: 2 ins; 4 del; 8 mod

8371320: runtime/ErrorHandling/PrintVMInfoAtExitTest.java fails with unexpected amount for Java Heap reserved memory

Reviewed-by: azafari, jsikstro

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

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

From phubner at openjdk.org  Fri Nov 14 08:35:05 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 14 Nov 2025 08:35:05 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap
In-Reply-To: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
Message-ID: <iUHBoZIDxaEfK8iKzfVT-E3FfqdfotRGnC5Sp_hEcbY=.06598290-1678-40dc-8844-ec041714ab7f@github.com>

On Thu, 13 Nov 2025 09:16:34 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.
> 
> Testing: GHA

LGTM, thanks.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/28285#pullrequestreview-3463628475

From phubner at openjdk.org  Fri Nov 14 08:39:07 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 14 Nov 2025 08:39:07 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v4]
In-Reply-To: <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
 <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
Message-ID: <TgHsj-IZcWh8J9KaXLTsercqYDmpwSD0kGt4OGkYYQA=.f953593c-3bb2-4dfc-b515-bc0e108d5ae6@github.com>

On Thu, 13 Nov 2025 15:31:52 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
>> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
>> 
>> The fix is to skip cases where page-number under checking is `-1`.
>> Tested under UBSAN build.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   style and not constexpr

Thanks for doing this.

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

Marked as reviewed by phubner (Author).

PR Review: https://git.openjdk.org/jdk/pull/28151#pullrequestreview-3463654131

From jsikstro at openjdk.org  Fri Nov 14 08:39:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 14 Nov 2025 08:39:24 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v5]
In-Reply-To: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
Message-ID: <aG96CbcqSgg2CWupJ4k3hUo3ZUyAhJatlIVc6tr29i8=.aefc994b-5612-451a-8d4f-a474e8e43285@github.com>

> Hello,
> 
> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
> 
> Testing:
> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
> * Running through Oracle's tier1-2

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Offline review feedback from Axel

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28261/files
  - new: https://git.openjdk.org/jdk/pull/28261/files/26765e87..49693773

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

  Stats: 19 lines in 1 file changed: 10 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28261/head:pull/28261

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

From azafari at openjdk.org  Fri Nov 14 08:39:10 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 14 Nov 2025 08:39:10 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v4]
In-Reply-To: <vR59j8XpHzMbie2imbHan4NGSDLcCGVKt-hg0OJlUNg=.6ffd40ec-edae-4b7e-b9fb-e45deefd56ef@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
 <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
 <vR59j8XpHzMbie2imbHan4NGSDLcCGVKt-hg0OJlUNg=.6ffd40ec-edae-4b7e-b9fb-e45deefd56ef@github.com>
Message-ID: <ME5kjGmQIC3b6nLQOtIYa1YICrUJnHYbw6lGTc_oz4w=.e9101c5e-7b94-40aa-9662-c6be05106043@github.com>

On Fri, 14 Nov 2025 08:28:30 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style and not constexpr
>
> test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 97:
> 
>> 95:         continue;
>> 96:       }
>> 97:       address page_addr = base + page_num[index] * page_sz;
> 
> What if we `assert(page_num[index] >= 0)` at this point if we know that negative numbers may cause overflows?

Negative numbers are not bug/invalid. They are used as a marker that the page is inside a committed region.
In the test we list/iterate all committed regions of a reserved memory are. For each committed region we check a list of pages whether the page is inside the committed region or not. if yes, we mark the page with -1. There two loops here one for committed regions and for list of page numbers.
After loops, we check and expect that all the pages were marked as being inside committed regions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28151#discussion_r2526466012

From azafari at openjdk.org  Fri Nov 14 09:07:14 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 14 Nov 2025 09:07:14 GMT
Subject: RFR: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow [v4]
In-Reply-To: <ADJK9A76_qVr0TDa8un-ayAXFNvlU9sS8FSx1dJiAwM=.33adbcae-ddc0-42f7-b8c8-66444b42572e@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
 <pVnfFpeQyl4p162jQXcddQOfd4zQz-kknkPfm58GT3Y=.ffb1e8b8-fb7f-4b78-aafa-f7f3a18ca766@github.com>
 <ADJK9A76_qVr0TDa8un-ayAXFNvlU9sS8FSx1dJiAwM=.33adbcae-ddc0-42f7-b8c8-66444b42572e@github.com>
Message-ID: <OFjXnkPiyVHDu36h3DoJqCMQMarCjkOB_bEcktqCLx0=.2ac3c4f5-a67d-48e6-8246-ab42b0f8f4bc@github.com>

On Fri, 14 Nov 2025 07:49:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style and not constexpr
>
> Marked as reviewed by jsjolen (Reviewer).

Thank you @jdksjolen and @Arraying for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28151#issuecomment-3531683600

From azafari at openjdk.org  Fri Nov 14 09:07:16 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 14 Nov 2025 09:07:16 GMT
Subject: Integrated: 8361487: [ubsan] test_committed_virtualmemory.cpp
 check_covered_pages shows overflow
In-Reply-To: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
References: <1-FPLsQshdDaSUDJ_BklYLmWCQuhm_Dob1eJuuTOGW4=.2fbdb61c-cc03-4756-8840-dd274edf4f23@github.com>
Message-ID: <nKwfE9mTY-V6bTpPeriZCmYqbFhqgZ4LaubXFrp1sZY=.75b5dbc3-c291-4409-896c-0f3a49e33e72@github.com>

On Wed, 5 Nov 2025 14:55:05 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> In the test,  page-numbers to be checked are passed to a checker function in which they will be changed to `-1` if they are as expected.
> Use of these `-1` values for page-numbers in consequent checks result in overflow in pointer arithmetic of `base + (-1) * page_size` which is certainly less than `base`.
> 
> The fix is to skip cases where page-number under checking is `-1`.
> Tested under UBSAN build.

This pull request has now been integrated.

Changeset: 9eaa364a
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9eaa364a5221cba960467ffbaea14ea790809c6a
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

8361487: [ubsan] test_committed_virtualmemory.cpp check_covered_pages shows overflow

Reviewed-by: jsjolen, phubner

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

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

From nbenalla at openjdk.org  Fri Nov 14 09:47:49 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 14 Nov 2025 09:47:49 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v5]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <bXAj8GvbPQ59D2rYGXaM4lLTonXCT8OpR5Qw4h1p_6Y=.3650db88-2f42-422e-af89-0ae9b3db348b@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into start-of-release-27
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Merge branch 'master' into start-of-release-27
 - update links to JVMS 26 and 27
 - add missing enum
 - initial commit start-of-JDK-27

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

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

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

  Stats: 14293 lines in 184 files changed: 9629 ins; 3659 del; 1005 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

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

From ayang at openjdk.org  Fri Nov 14 09:48:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 14 Nov 2025 09:48:16 GMT
Subject: RFR: 8371874: AOTLinkedClassBulkLoader::preload_classes() should
 not allocate heap objects
In-Reply-To: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>
References: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>
Message-ID: <3cxj27LT4AdyylNIJ3TAUJBheo_dI6lw86GITeCdAR4=.54475eff-cc42-41d0-8b74-6595c79b3bd9@github.com>

On Fri, 14 Nov 2025 04:43:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `AOTLinkedClassBulkLoader::preload_classes()` indirectly calls `java_lang_Class::restore_archived_mirror()` which can allocate an `int` array for the `init_lock`. However, the `init_lock` has already been allocated during AOT cache assembly :
> 
> 
> java_lang_Class::create_scratch_mirror()
> -> allocate_mirror()
>   -> initialize_mirror_fields()
>     -> set_init_lock()
> 
> 
> So there's no need to allocate it again in the production run.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28315#pullrequestreview-3464008421

From ayang at openjdk.org  Fri Nov 14 10:14:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 14 Nov 2025 10:14:03 GMT
Subject: RFR: 8371607: Remove GCSharedStringsDuringDumpWb.java after
 JDK-8362561
In-Reply-To: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
References: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
Message-ID: <psPn6mVMddsFBn-buaW6bthXEEY9zV0rtXCM0SfV43A=.a6536cd0-a6d5-4e85-910f-f10e9e59ef1a@github.com>

On Thu, 13 Nov 2025 16:49:32 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) removed `runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java` which was the only place where `GCSharedStringsDuringDumpWb.java` was used. Therefore, `GCSharedStringsDuringDumpWb.java` should be cleaned up.
> 
> Testing: tiers 1-3 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28300#pullrequestreview-3464145172

From aboldtch at openjdk.org  Fri Nov 14 10:38:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 14 Nov 2025 10:38:03 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v5]
In-Reply-To: <aG96CbcqSgg2CWupJ4k3hUo3ZUyAhJatlIVc6tr29i8=.aefc994b-5612-451a-8d4f-a474e8e43285@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <aG96CbcqSgg2CWupJ4k3hUo3ZUyAhJatlIVc6tr29i8=.aefc994b-5612-451a-8d4f-a474e8e43285@github.com>
Message-ID: <PDtey-xYh2dk6tYUx03aCY3NmcXLqOWfoO6y3UbkeoA=.a39586e7-8288-4782-a74b-1cde7430a37f@github.com>

On Fri, 14 Nov 2025 08:39:24 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
>> 
>> Testing:
>> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
>> * Running through Oracle's tier1-2
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Offline review feedback from Axel

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28261#pullrequestreview-3464272040

From mbaesken at openjdk.org  Fri Nov 14 10:40:46 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 10:40:46 GMT
Subject: RFR: 8333871: check sysinfo return values
Message-ID: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>

In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
However we miss checking the return values at some places, this might need adjustment.

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

Commit messages:
 - JDK-8333871

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

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

From azafari at openjdk.org  Fri Nov 14 10:47:05 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 14 Nov 2025 10:47:05 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap
In-Reply-To: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
Message-ID: <KJr45NAdpQXLBolNSa07ovHFl5tpsBCAWtJPLBcoYyI=.97a646f8-e73a-41e5-a129-14deddb39261@github.com>

On Thu, 13 Nov 2025 09:16:34 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.
> 
> Testing: GHA

src/hotspot/share/nmt/memMapPrinter.cpp line 131:

> 129:   }
> 130: 
> 131:   // Given a vma [from, to), find all regions that intersect with this vma and

Maybe the comment can be updated. There is no return now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28285#discussion_r2527021738

From jsjolen at openjdk.org  Fri Nov 14 10:51:23 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 10:51:23 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap [v2]
In-Reply-To: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
Message-ID: <FzBoq9wMeJH74r0Af2GQv2GWGmc7oss5pANdWVWrmoM=.4d398a26-dc06-4bd0-b43f-b7519328d67e@github.com>

> Hi,
> 
> We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.
> 
> Testing: GHA

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Change comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28285/files
  - new: https://git.openjdk.org/jdk/pull/28285/files/abd8dc03..86b81e32

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

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

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

From jsjolen at openjdk.org  Fri Nov 14 10:51:25 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 10:51:25 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap [v2]
In-Reply-To: <KJr45NAdpQXLBolNSa07ovHFl5tpsBCAWtJPLBcoYyI=.97a646f8-e73a-41e5-a129-14deddb39261@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
 <KJr45NAdpQXLBolNSa07ovHFl5tpsBCAWtJPLBcoYyI=.97a646f8-e73a-41e5-a129-14deddb39261@github.com>
Message-ID: <WLA0jsIxFXvvgnnqLqcEY6S_FRos1iYvKjsQ_KTtIvQ=.5136ae3a-7249-4683-9db0-5271ad2757fc@github.com>

On Fri, 14 Nov 2025 10:44:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change comment
>
> src/hotspot/share/nmt/memMapPrinter.cpp line 131:
> 
>> 129:   }
>> 130: 
>> 131:   // Given a vma [from, to), find all regions that intersect with this vma and
> 
> Maybe the comment can be updated. There is no return now.

Good point, I changed it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28285#discussion_r2527034819

From jpai at openjdk.org  Fri Nov 14 10:55:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 14 Nov 2025 10:55:10 GMT
Subject: RFR: 8333871: check sysinfo return values
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <JjvDS8FMBKXRIcbEdRUVM4buJDbvY8YGBciY6SlRda4=.776093c2-c71b-460c-87b7-a083df84b11b@github.com>

On Fri, 14 Nov 2025 10:33:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

src/java.base/unix/native/libjava/java_props_md.c line 394:

> 392:         if (ret == 0) {
> 393:             sprops.cpu_isalist = strdup(list);
> 394:             list[sizeof(list) - 1] = '\0';

Hello Matthias, is this a typo? The assignment to `list` which is no longer used after the previous line where it is duplicated, seems odd. Furthermore, is this explicit null termination needed? In `man strdup` I don't see any such expectations:

> The strdup() function returns a pointer to a new string which is a duplicate of the string s.  Memory for the new string is obtained with malloc(3), and can be freed with free(3).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527051473

From stuefe at openjdk.org  Fri Nov 14 11:00:16 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Nov 2025 11:00:16 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
 <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
 <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>
Message-ID: <mA2pkkPtDQSePh_g2csbK-BeOJDbQ90zAvjl56xamdg=.c881dc2c-e282-49bf-bad1-c840e538851c@github.com>

On Mon, 10 Nov 2025 14:13:48 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> I see what you mean. 
>> 
>> Ugh. I forgot that we cannot selectively poison write access only but still allow read access, because otherwise poisoning the whole header would be much simpler and nicer. But unpoisoning every time one checks a header would be highly annoying.
>> 
>> In order to simplify, and not to pay too high a penalty on access if ASAN is enabled, I would consider:
>> - don't bother poisoning `_size`. This field is frequently accessed, as opposed to the `_canary` field. I think cases where we overwrite `_size` but *don't* overwrite either the byte before it (which should be guarded by ASAN anyway since it precedes the first valid byte) or the canary (which is now also poisoned and directly precedes the user payload) should be exceedingly rare. 
>> - I would just not bother checking NMT block integrity at all if ASAN is enabled. That should reduce the number of accesses to the `_canary` to zero, and since ASAN reports right away when the canary is hit, we will see it right away. Now you won't need unpoisoning on canary read.
>
> Wouldn't this lead to more branches in the code, and questions like "why is this poisoned, but not _size?" etc? I wouldn't call the `_size` field in the header frequently accessed (once at malloc, once at free, any I'm missing?), it's more than 0 I guess :-).
> 
> I haven't measured, so grains of salt and so on, but the cost of ASAN is already high, I don't think any additional cost to poisoning/unpoisoning NMT headers at malloc/free is going to add too much of a perf hit.

Hm, okay. I refreshed my memory, and yes, we only access the header on malloc and free. But then, what exactly is the purpose of selectively poisoning size and the canary, but leaving the rest unpoisoned? Either we must have perfect coverage - in which case we should poison the whole header - or we are happy with a 99% solution, in which case it's sufficient to poison only the canaries. Either way would be preferable to what the patch does now, which feels a bit arbitrary.

Also, since we only access the header on os::malloc/realloc/free, we can move up the RAII unpoisoning helper to those functions and reduce the number of invocations from 16 to three call sites.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527077104

From mbaesken at openjdk.org  Fri Nov 14 11:07:20 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 11:07:20 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

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

  0 - terminate not needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/2d574f7c..e9d2b1b4

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

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

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

From jsikstro at openjdk.org  Fri Nov 14 11:11:35 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 14 Nov 2025 11:11:35 GMT
Subject: RFR: 8371607: Remove GCSharedStringsDuringDumpWb.java after
 JDK-8362561
In-Reply-To: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
References: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
Message-ID: <qI2gRNQvL-l5L8yF7k-SaEFjvftp9MZDEa-2qpB1_kg=.9c0249c1-da69-444e-844a-0a0ed4875656@github.com>

On Thu, 13 Nov 2025 16:49:32 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) removed `runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java` which was the only place where `GCSharedStringsDuringDumpWb.java` was used. Therefore, `GCSharedStringsDuringDumpWb.java` should be cleaned up.
> 
> Testing: tiers 1-3 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Thank you for taking care of this!

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28300#pullrequestreview-3464425928

From jsikstro at openjdk.org  Fri Nov 14 11:14:52 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 14 Nov 2025 11:14:52 GMT
Subject: RFR: 8371894: Minor style fixes in AOT/CDS code
Message-ID: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>

Hello,

While working on [JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035) we have noticed some minor inconsistencies in code related to AOT and CDS which should be fixed.

Testing:
* GHA

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

Commit messages:
 - 8371894: Minor style fixes in AOT/CDS code

Changes: https://git.openjdk.org/jdk/pull/28318/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28318&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371894
  Stats: 30 lines in 4 files changed: 3 ins; 4 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/28318.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28318/head:pull/28318

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

From mbaesken at openjdk.org  Fri Nov 14 11:07:22 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 11:07:22 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <JjvDS8FMBKXRIcbEdRUVM4buJDbvY8YGBciY6SlRda4=.776093c2-c71b-460c-87b7-a083df84b11b@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <JjvDS8FMBKXRIcbEdRUVM4buJDbvY8YGBciY6SlRda4=.776093c2-c71b-460c-87b7-a083df84b11b@github.com>
Message-ID: <Ag3Gn6fC_CIpWvMdO28JD3eUVRR-W7ytxz3alLwAe_0=.0c132c7d-7feb-459f-a521-b3d903e8df9d@github.com>

On Fri, 14 Nov 2025 10:51:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   0 - terminate not needed
>
> src/java.base/unix/native/libjava/java_props_md.c line 394:
> 
>> 392:         if (ret == 0) {
>> 393:             sprops.cpu_isalist = strdup(list);
>> 394:             list[sizeof(list) - 1] = '\0';
> 
> Hello Matthias, is this a typo? The assignment to `list` which is no longer used after the previous line where it is duplicated, seems odd. Furthermore, is this explicit null termination needed? In `man strdup` I don't see any such expectations:
> 
>> The strdup() function returns a pointer to a new string which is a duplicate of the string s.  Memory for the new string is obtained with malloc(3), and can be freed with free(3).

Hi , I removed the 0 - termination. Seems it is not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527094141

From stuefe at openjdk.org  Fri Nov 14 11:41:11 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Nov 2025 11:41:11 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <mA2pkkPtDQSePh_g2csbK-BeOJDbQ90zAvjl56xamdg=.c881dc2c-e282-49bf-bad1-c840e538851c@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
 <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
 <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>
 <mA2pkkPtDQSePh_g2csbK-BeOJDbQ90zAvjl56xamdg=.c881dc2c-e282-49bf-bad1-c840e538851c@github.com>
Message-ID: <RzLeiXgH1FcR6WDQhn_HgCSWpzBbQPsK27Jlb4XguWQ=.091fd006-95e9-4112-a330-e6a1b654fc5b@github.com>

On Fri, 14 Nov 2025 10:57:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Wouldn't this lead to more branches in the code, and questions like "why is this poisoned, but not _size?" etc? I wouldn't call the `_size` field in the header frequently accessed (once at malloc, once at free, any I'm missing?), it's more than 0 I guess :-).
>> 
>> I haven't measured, so grains of salt and so on, but the cost of ASAN is already high, I don't think any additional cost to poisoning/unpoisoning NMT headers at malloc/free is going to add too much of a perf hit.
>
> Hm, okay. I refreshed my memory, and yes, we only access the header on malloc and free. But then, what exactly is the purpose of selectively poisoning size and the canary, but leaving the rest unpoisoned? Either we must have perfect coverage - in which case we should poison the whole header - or we are happy with a 99% solution, in which case it's sufficient to poison only the canaries. Either way would be preferable to what the patch does now, which feels a bit arbitrary.
> 
> Also, since we only access the header on os::malloc/realloc/free, we can move up the RAII unpoisoning helper to those functions and reduce the number of invocations from 16 to three call sites.

I take back what I wrote. From looking into how UNPOISON is implemented, we dive down into libsanitizer for every single call to unpoison, and that function is non-trivial. So I would prefer to protect the malloc header in its whole.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527132246

From stuefe at openjdk.org  Fri Nov 14 11:41:12 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Nov 2025 11:41:12 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <RzLeiXgH1FcR6WDQhn_HgCSWpzBbQPsK27Jlb4XguWQ=.091fd006-95e9-4112-a330-e6a1b654fc5b@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
 <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
 <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>
 <mA2pkkPtDQSePh_g2csbK-BeOJDbQ90zAvjl56xamdg=.c881dc2c-e282-49bf-bad1-c840e538851c@github.com>
 <RzLeiXgH1FcR6WDQhn_HgCSWpzBbQPsK27Jlb4XguWQ=.091fd006-95e9-4112-a330-e6a1b654fc5b@github.com>
Message-ID: <GL4Kvlvp-u7L54LXtKBxfNL01knDVCfcrINfg9T8tbo=.656bcc05-6ebd-420b-9c1b-234358639c05@github.com>

On Fri, 14 Nov 2025 11:17:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hm, okay. I refreshed my memory, and yes, we only access the header on malloc and free. But then, what exactly is the purpose of selectively poisoning size and the canary, but leaving the rest unpoisoned? Either we must have perfect coverage - in which case we should poison the whole header - or we are happy with a 99% solution, in which case it's sufficient to poison only the canaries. Either way would be preferable to what the patch does now, which feels a bit arbitrary.
>> 
>> Also, since we only access the header on os::malloc/realloc/free, we can move up the RAII unpoisoning helper to those functions and reduce the number of invocations from 16 to three call sites.
>
> I take back what I wrote. From looking into how UNPOISON is implemented, we dive down into libsanitizer for every single call to unpoison, and that function is non-trivial. So I would prefer to protect the malloc header in its whole.

BTW, the argument "the cost of ASAN is already high" is not a good one. We use ASAN in production to find real issues in sometimes large applications that may run a while before hitting an error. Every minute saved here is beneficial.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527145908

From stuefe at openjdk.org  Fri Nov 14 11:41:17 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Nov 2025 11:41:17 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v21]
In-Reply-To: <2UfkSzuxH68EuDt0x5oY_Hy2Mxm3JT68vwTj9MXZW1w=.1e5c9ca2-bfb3-4ddd-82a7-6164516fd239@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <2UfkSzuxH68EuDt0x5oY_Hy2Mxm3JT68vwTj9MXZW1w=.1e5c9ca2-bfb3-4ddd-82a7-6164516fd239@github.com>
Message-ID: <In9nQGTMOLgKzmaZtgCg84w4GeExkXbKk9FoZsHYIw4=.9812cdd6-19fe-4cb8-9e40-9e73a859b831@github.com>

On Mon, 10 Nov 2025 20:03:35 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NNT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improvements.

src/hotspot/share/sanitizers/address.hpp line 80:

> 78: 
> 79: template<typename T>
> 80: class AsanPoisoningHelper {

It would be preferable not to have it as a template, since one may want to use this with memory ranges whose sizes are not known at compile time. Just make the size a const member.

In addition to that, I am unsure we want to make it this easy to protect infinitesimal small memory ranges (e.g. uint16_t) before we have an idea of the overhead costs of every poison call. Especially if this is meant to be a general purpose class, not only for NMT malloc and free.

src/hotspot/share/sanitizers/address.hpp line 81:

> 79: template<typename T>
> 80: class AsanPoisoningHelper {
> 81:   const T* _memory_region;

The pointer should be const.

src/hotspot/share/sanitizers/address.hpp line 85:

> 83:   AsanPoisoningHelper() = delete;
> 84:   AsanPoisoningHelper(const T* addr) : _memory_region(addr) {
> 85:     #if INCLUDE_ASAN

We use ADDRESS_SANITIZER in other places in this file, so I would use that.

In addition, I would wrap the whole class into ADDRESS_SANITIZER and not do this for the individual functions. And provide a simple stub for the non-ASAN case.

test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 184:

> 182: 
> 183: #else // ASAN is enabled
> 184: 

Do we really need to duplicate this macro, just to give the test an own name? Certainly this can be simplified?

test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 202:

> 200:   *canary_ptr = 1;
> 201: }
> 202: 

If we simplify to poisoning the whole header (or just the canary itself) this whole section can be shrunk down to two test functions.

Otherwise, there is a large potential for simplification here. A lot of that code is duplicated.

Also note that there is a time cost involved with very fine-grained tests like these. Death tests take a long time, since they involve forking new processes, starting the JVM, letting it crash, and writing the hs_err.log file. Seeing that we basically just test different offsets in the header, the usefulness of this many tests is questionable. 

I think I would reduce this to just one test, or maybe two if you want to be thorough and test both start and end of header. Arguably the only test really needed is the test for the canary, since it borders the user section directly and is the first to be hit on a buffer overflow.

As I wrote before: the section *preceding* the header is protected by ASAN anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527097852
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527104017
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527186265
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527153855
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527159978

From jsjolen at openjdk.org  Fri Nov 14 11:47:15 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 11:47:15 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <GL4Kvlvp-u7L54LXtKBxfNL01knDVCfcrINfg9T8tbo=.656bcc05-6ebd-420b-9c1b-234358639c05@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
 <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
 <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>
 <mA2pkkPtDQSePh_g2csbK-BeOJDbQ90zAvjl56xamdg=.c881dc2c-e282-49bf-bad1-c840e538851c@github.com>
 <RzLeiXgH1FcR6WDQhn_HgCSWpzBbQPsK27Jlb4XguWQ=.091fd006-95e9-4112-a330-e6a1b654fc5b@github.com>
 <GL4Kvlvp-u7L54LXtKBxfNL01knDVCfcrINfg9T8tbo=.656bcc05-6ebd-420b-9c1b-234358639c05@github.com>
Message-ID: <42zufSBN8oVXdRilwv0ZasY8vAn9PajYHakHlhdGXZo=.a88d9d8d-357b-48de-ac07-f0b05f90b1c3@github.com>

On Fri, 14 Nov 2025 11:22:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>We use ASAN in production to find real issues in sometimes large applications that may run a while before hitting an error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527210687

From azafari at openjdk.org  Fri Nov 14 11:54:09 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 14 Nov 2025 11:54:09 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap [v2]
In-Reply-To: <FzBoq9wMeJH74r0Af2GQv2GWGmc7oss5pANdWVWrmoM=.4d398a26-dc06-4bd0-b43f-b7519328d67e@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
 <FzBoq9wMeJH74r0Af2GQv2GWGmc7oss5pANdWVWrmoM=.4d398a26-dc06-4bd0-b43f-b7519328d67e@github.com>
Message-ID: <H49EuiAmOfgkalrXheEu3gWlmO2eDWuRDfvM_TEW4W0=.9cfaeff2-3b1f-45fd-a4a4-84ef9c193297@github.com>

On Fri, 14 Nov 2025 10:51:23 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.
>> 
>> Testing: GHA
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comment

Thank you for taking this.
I found a possible super tiny fix.

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

PR Review: https://git.openjdk.org/jdk/pull/28285#pullrequestreview-3464590624

From stuefe at openjdk.org  Fri Nov 14 11:55:17 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Nov 2025 11:55:17 GMT
Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive
 red-black tree
In-Reply-To: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>
References: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>
Message-ID: <xWadlUrVuEKMrMRoRL3zKgtCHFhAJmg3esJ6olQ-Qo8=.ea590398-c74c-4ad7-a832-79b25176a224@github.com>

On Thu, 11 Sep 2025 09:40:21 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> Metaspace's `BlockTree` is currently implemented as a simple binary search tree, using the memory blocks it stores as the nodes. While this is straightforward and generally fine, it can become unbalanced depending on insert/remove order, leading to degraded performance.
> 
> This is a good fit for the utilities `IntrusiveRBTree`, instead of using internal tree logic. With it, we can replace all tree functions and instead rely on a few insert/remove calls. `BlockTree` still remains as the layer coordinating these blocks, and still handles the list of same-size nodes. The intrusive red-black tree only handles balancing and linking/unlinking nodes in the tree structure. 
> 
> Validation and printing are preserved by using the hooks provided by the red-black tree. We keep the same checks (and get a few more from the rb-tree), and the printed output is kept identical. The only real difference is that the red-black tree traverses the tree instead.
> 
> Testing:
> - Oracle tiers 1-8

I saw this just now. I guess this makes sense, but I admit I feel a bit apprehensive about this. Is the RBTree already mature enough? Have we ironed out all issues?

Can you please test:
- that the number of freeblock nodes stays the same pre- and post-patch? (Easiest would be with VM metaspace, I think I print out freeblock statistics somewhere)
- that the number of malloc blocks from Metaspace stays the same or that we can explain differences for a simple test? (the old tree lived completely in metaspace and needed no secondary structures; I just want to make sure its still the case. I have not looked at the new RB tree implementation for a while).

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

PR Comment: https://git.openjdk.org/jdk/pull/27212#issuecomment-3532388629

From ayang at openjdk.org  Fri Nov 14 11:54:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 14 Nov 2025 11:54:12 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <G0xVQpc_FSma3WnGWCHVJMdprWwW86IKyICAFeQJ29k=.cd4cff1c-b67f-4616-8c19-260435956bf1@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28157#pullrequestreview-3464591706

From jsjolen at openjdk.org  Fri Nov 14 12:00:37 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 12:00:37 GMT
Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive
 red-black tree
In-Reply-To: <xWadlUrVuEKMrMRoRL3zKgtCHFhAJmg3esJ6olQ-Qo8=.ea590398-c74c-4ad7-a832-79b25176a224@github.com>
References: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>
 <xWadlUrVuEKMrMRoRL3zKgtCHFhAJmg3esJ6olQ-Qo8=.ea590398-c74c-4ad7-a832-79b25176a224@github.com>
Message-ID: <LZGtKlXmW9etG4dds1LzMLIuVsF6jwT6P_0T6ISPp_c=.da0bed2d-0f45-4f0f-834f-fb50286030f6@github.com>

On Fri, 14 Nov 2025 11:52:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I saw this just now. I guess this makes sense, but I admit I feel a bit apprehensive about this. Is the RBTree already mature enough? Have we ironed out all issues?
> 
> Can you please test:
> 
>     * that the number of freeblock nodes stays the same pre- and post-patch? (Easiest would be with VM metaspace, I think I print out freeblock statistics somewhere)
> 
>     * that the number of malloc blocks from Metaspace stays the same or that we can explain differences for a simple test? (the old tree lived completely in metaspace and needed no secondary structures; I just want to make sure its still the case. I have not looked at the new RB tree implementation for a while).

We can await RDP1 and integrate this after that. It's closing in on that anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/27212#issuecomment-3532406021

From aartemov at openjdk.org  Fri Nov 14 12:04:26 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:26 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v7]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <-UqELJ5fcs2hmKx51_i77VwQGSq70cV4Wd73_6YkcGA=.2d572210-d0f7-45a1-9fd4-9b06f2e5609c@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible. There are two places where it can happen:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Fixed the test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/702880c6..15efce1b

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

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

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

From aartemov at openjdk.org  Fri Nov 14 12:04:30 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:30 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <EJ_2JtkgOOE3VyGQ6HwYqRzgLPOLqvrDnwrB2UR-UTg=.656ee22e-3619-424c-a69c-722628de56d1@github.com>
Message-ID: <1sh5xXfgN3ykKP6JO7fkEO-06usdJoBMp_igGw9OzJI=.b9325a92-1e8d-49a2-aaed-b7a154d9bb6a@github.com>

On Thu, 13 Nov 2025 20:50:57 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> So the bug report talks about two different deadlocks and we have added two new test cases to SuspendWithObjectMonitorWait.java.
> 
> I think the new `doWork2` test case is added to catch deadlock-1 when we have a suspended
> thread made the successor over and over again so that none of the other contending threads
> ever get the monitor even though it is unlocked.
> 
> I think the new `doWork3` test case is added to catch deadlock-2 where the waiting thread
> manages to re-enter the monitor and then gets suspended while on its way back to Java.
> 
> @toxaart and/or @pchilano - Please verify my understanding of this mapping from the two
> new test cases to the two deadlocks. Thanks!

Thanks @dcubed-ojdk and @pchilano, I addressed all the points. The diagrams are now added to the test.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 110:
> 
>> 108: 
>> 109:     public static void main(String[] args) throws Exception {
>> 110:         int test = Integer.parseInt(args[0]);
> 
> I think this will throw if the test is called without any parameters.
> 
> Also, the `usage` function needs to be updated to reflect the addition of the
> test number parameter.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 297:
> 
>> 295:     }
>> 296: 
>> 297:     // Notify the resumer while holding the threadLock
> 
> Nit: please add a period at the end of this sentence.

Addressed in the latest commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3532412149
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527249217
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527245664

From aartemov at openjdk.org  Fri Nov 14 12:04:32 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <dixtIsBamOGvMeZR4FXJlv4O6DVoaXbW9tTSv2BHjow=.17ee7cff-0729-49fa-8735-e9f1b4297b4c@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <NKeETIKRG6X8sUCeisB_Kmbp2Ufvt1MN7QH48Cz8Vg8=.c418c7f7-9a7d-44ba-a1a8-e7149985d47f@github.com>
 <dixtIsBamOGvMeZR4FXJlv4O6DVoaXbW9tTSv2BHjow=.17ee7cff-0729-49fa-8735-e9f1b4297b4c@github.com>
Message-ID: <4J4hAvATWVRnKGA8E1_R2dYYY-QPd6rWm6BQECf2jpI=.e624cd45-7b4b-4f55-a870-3cfb66f577c4@github.com>

On Thu, 13 Nov 2025 20:34:46 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 31:
>> 
>>> 29:  * @library /test/lib
>>> 30:  * @compile SuspendWithObjectMonitorWait.java
>>> 31:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 1
>> 
>> Note that these passed values are overriding timeMax.
>
> The addition of the test number should have been done as a required parameter.
> That would push the optional timeMax parameter to be the optional second parameter.

Addressed in the latest commit. I did not figure out how to do it with jtreg, made it instead right in the test code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527248823

From aartemov at openjdk.org  Fri Nov 14 12:04:32 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <TYLevWiK7oXdTDwG-dmB4De8iwR9pQr_EEPbsu0MXCQ=.e4743b79-9874-4abd-8a9e-38cf6b6d534b@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <01keWsXsYrIpmL3GwgAFqXYuTxfM1ohW_J9FWsGsnIA=.84c0fbc2-df37-45e0-99eb-f7291dc33410@github.com>
 <TYLevWiK7oXdTDwG-dmB4De8iwR9pQr_EEPbsu0MXCQ=.e4743b79-9874-4abd-8a9e-38cf6b6d534b@github.com>
Message-ID: <qRVdIum5zsImnH0HZXysbFYpgbM751r6-_zydPGP72k=.3eaa9660-dcaa-4f8f-a338-72118a8d6e4a@github.com>

On Thu, 13 Nov 2025 20:36:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> I can't figure out why we're delaying the resumer thread in `doWork2`.
>
> Update: I figured this out. See the new doWork2 transaction diagram.

Addressed.

>> I can't figure out why we're delaying the resumer thread in `doWork3`.
>
> Update: I figured this out. See the new doWork3 transaction diagram.

Addressed the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527246445
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527246193

From aartemov at openjdk.org  Fri Nov 14 12:04:33 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <O4k-l4EhvJP0d-ixsj-QLSvjRcXcBNEyhKhk88OqXug=.7bbc2991-088d-48fd-9afe-a3c5fc0fbca1@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <mKglt6pxRZyl7RFV5cYkR08hUpoY0YeIbc-CkcDujM4=.f6df50fc-78e3-4d3e-8602-a883a3cb5c5c@github.com>
 <HY-TJtrEUuC4FkVIXfLgtpMnB3aCECZ1Qnpj-b-h4jM=.10b0895a-1db6-4a75-836d-b5bcc3da1649@github.com>
 <O4k-l4EhvJP0d-ixsj-QLSvjRcXcBNEyhKhk88OqXug=.7bbc2991-088d-48fd-9afe-a3c5fc0fbca1@github.com>
Message-ID: <kBR_mo5mAZQO4xyfJ9_CnKl98Bv9eoCZ-MyZTxhGt4k=.228dcc7a-328d-466c-baa5-59a0e5a5f4ff@github.com>

On Thu, 13 Nov 2025 20:38:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> The `notify()` call doesn?t unpark the waiter thread, it just moves it from the `_wait_set` to the `_entry_list`. The wait(timeout) is there to allow it to run again so that it is suspended in `reenter_internal()`. But currently the timings will not exercise this case well. I added some comments to fix it.
>
> Please see the notes in the new doWork3 transaction diagram. I think I've covered this case.

Thanks @dcubed-ojdk! I added your diagrams to the test.

>> This sleep is not needed.
>
> I have a comment about this in the new doWork3 transaction diagram.

Removed as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527248191
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527245983

From aartemov at openjdk.org  Fri Nov 14 12:04:36 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:04:36 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v6]
In-Reply-To: <B2pu1K767Mx5pPslzgv4i03cpeC3hmtSlzTquOvcJ6o=.f04ea9be-b689-441b-9a43-8905f138dba6@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <dvnZBhTKis0ej8jTqn6zC0i9-5TTuo_myC4YyhRo1bo=.52297822-afa9-4418-984d-85f64b157f61@github.com>
 <B2pu1K767Mx5pPslzgv4i03cpeC3hmtSlzTquOvcJ6o=.f04ea9be-b689-441b-9a43-8905f138dba6@github.com>
Message-ID: <dt5IFHCnLsTSSVT0CWWbPGUSWHTOCHWbGPzCVKVLYcM=.2f73701a-d614-49bb-9e59-95f2f9df7f15@github.com>

On Thu, 13 Nov 2025 19:13:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Removed incorrect assert,
>>  - 8366659: Fixed merge conflict
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/400a83da...702880c6
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 428:
> 
>> 426:             // launch the waiter thread
>> 427:             synchronized (barrierLaunch) {
>> 428:                 waiter = new SuspendWithObjectMonitorWaitWorker("waiter", 1);
> 
> We should increase this timeout to minimize the chance of it happening between the main thread acquiring the `threadLock` and issuing the notification, in which case the waiter will not go through `reenter_internal` but through `enter`. Also it avoids some funny scheduling where the main thread never acquires the `threadLock`.

Done.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 466:
> 
>> 464:                 testState = TS_READY_TO_NOTIFY;
>> 465:                 threadLock.notify();
>> 466: 
> 
> We should add a `Thread.sleep` here to give time for the wait to timeout before suspending the waiter thread. Should be more than what the waiter thread is using as timeout. I have tested a timeout value of 100ms and here sleeping 200ms and always see the deadlock on `reenter_internal` (with current mainline code).

Removed the sleep which was not needed and added another one with 200ms as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527251981
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2527248616

From alanb at openjdk.org  Fri Nov 14 12:11:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 14 Nov 2025 12:11:01 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <ZT4iXoqROEqXtP7Tm_bdWzYsrCk_Hk1nt4Yyd8LzJ1Q=.79b0cbac-5ceb-46a0-bf49-b5c6dbdd0dc7@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

src/java.base/unix/native/libjava/java_props_md.c line 395:

> 393:             sprops.cpu_isalist = strdup(list);
> 394:         } else {
> 395:             sprops.cpu_isalist = NULL;

Would you mind checking the code that puts this in a system property can tolerate NULL? I don't suppose sysinfo will fail here (unless you found a case?) but it would be good to confirm that it won't blow up somewhere else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527272162

From aartemov at openjdk.org  Fri Nov 14 12:15:35 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 14 Nov 2025 12:15:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed the test.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed lines in tests.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Added a comment to a boolean arg for enter()
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed new lines.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=07
  Stats: 469 lines in 3 files changed: 397 ins; 44 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From cnorrbin at openjdk.org  Fri Nov 14 12:42:56 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 14 Nov 2025 12:42:56 GMT
Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive
 red-black tree
In-Reply-To: <LZGtKlXmW9etG4dds1LzMLIuVsF6jwT6P_0T6ISPp_c=.da0bed2d-0f45-4f0f-834f-fb50286030f6@github.com>
References: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>
 <xWadlUrVuEKMrMRoRL3zKgtCHFhAJmg3esJ6olQ-Qo8=.ea590398-c74c-4ad7-a832-79b25176a224@github.com>
 <LZGtKlXmW9etG4dds1LzMLIuVsF6jwT6P_0T6ISPp_c=.da0bed2d-0f45-4f0f-834f-fb50286030f6@github.com>
Message-ID: <Wyvzdhu17GXIHEEwDPb1s5DeyJobsu8zUq9KM312nAY=.9b6407fb-c61e-4e44-b580-6c5114bf6408@github.com>

On Fri, 14 Nov 2025 11:57:35 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I saw this just now. I guess this makes sense, but I admit I feel a bit apprehensive about this. Is the RBTree already mature enough? Have we ironed out all issues?

I believe it has matured enough. It is already used in NMT and C2 printing, and in ZGC to track physical memory very similarly to what is done in here.


> Can you please test:
> 
> * that the number of freeblock nodes stays the same pre- and post-patch? (Easiest would be with VM metaspace, I think I print out freeblock statistics somewhere)
> * that the number of malloc blocks from Metaspace stays the same or that we can explain differences for a simple test? (the old tree lived completely in metaspace and needed no secondary structures; I just want to make sure its still the case. I have not looked at the new RB tree implementation for a while).

The intrusive red-black tree lives entirely in outside memory and does not allocate any structures of its own, so the same freeblock nodes also become nodes for the red-black tree. Nothing of this should change, but I can test this further to confirm. 

> We can await RDP1 and integrate this after that. It's closing in on that anyway.

I have no problem waiting a little more to integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/27212#issuecomment-3532555599

From stuefe at openjdk.org  Fri Nov 14 12:49:31 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Nov 2025 12:49:31 GMT
Subject: RFR: 8367332: Replace BlockTree tree logic with an intrusive
 red-black tree
In-Reply-To: <Wyvzdhu17GXIHEEwDPb1s5DeyJobsu8zUq9KM312nAY=.9b6407fb-c61e-4e44-b580-6c5114bf6408@github.com>
References: <VQmOtDW155J_3gUbiw6oLRK7T1IfIANK4N1N2uvcorc=.28d226e0-b5db-4b26-a0f2-10e3374d7058@github.com>
 <xWadlUrVuEKMrMRoRL3zKgtCHFhAJmg3esJ6olQ-Qo8=.ea590398-c74c-4ad7-a832-79b25176a224@github.com>
 <LZGtKlXmW9etG4dds1LzMLIuVsF6jwT6P_0T6ISPp_c=.da0bed2d-0f45-4f0f-834f-fb50286030f6@github.com>
 <Wyvzdhu17GXIHEEwDPb1s5DeyJobsu8zUq9KM312nAY=.9b6407fb-c61e-4e44-b580-6c5114bf6408@github.com>
Message-ID: <QB_TBVNXLUMFIPJF145U40-qTruSd4oPylnexyPhowI=.fdb89f62-3682-4747-af72-48f5c9339baf@github.com>

On Fri, 14 Nov 2025 12:40:20 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> > I saw this just now. I guess this makes sense, but I admit I feel a bit apprehensive about this. Is the RBTree already mature enough? Have we ironed out all issues?
> 
> I believe it has matured enough. It is already used in NMT and C2 printing, and in ZGC to track physical memory very similarly to what is done in here.
> 
> > Can you please test:
> > 
> > * that the number of freeblock nodes stays the same pre- and post-patch? (Easiest would be with VM metaspace, I think I print out freeblock statistics somewhere)
> > * that the number of malloc blocks from Metaspace stays the same or that we can explain differences for a simple test? (the old tree lived completely in metaspace and needed no secondary structures; I just want to make sure its still the case. I have not looked at the new RB tree implementation for a while).
> 
> The intrusive red-black tree lives entirely in outside memory and does not allocate any structures of its own, so the same freeblock nodes also become nodes for the red-black tree. Nothing of this should change, but I can test this further to confirm.
> 
> > We can await RDP1 and integrate this after that. It's closing in on that anyway.
> 
> I have no problem waiting a little more to integrate.

Thank you. Let's wait for 27 with this one. I will give it a look until then.

I am fine with the direction of this patch. I think this was one of the reasons I pinged Johan(?) some time ago about writing a general-purpose RedBlack tree.

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

PR Comment: https://git.openjdk.org/jdk/pull/27212#issuecomment-3532574019

From kevinw at openjdk.org  Fri Nov 14 13:01:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Nov 2025 13:01:08 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
Message-ID: <RSjjzwKMG4-YqC9lcW07Je0dchm3G2efkD8sGpmkQiU=.ace856e5-2c8b-43c0-a5a0-aeaab317a679@github.com>

On Thu, 13 Nov 2025 19:41:40 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - Error! Not a recording run
>> - Error! Not recording
>> - Recording ended successfully
>> - Error! Failed to end recording
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully
>> - Error! Not recording
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document use of DiagnosticCommand

src/hotspot/share/services/diagnosticCommand.cpp line 991:

> 989: }
> 990: 
> 991: #if INCLUDE_CDS

A simple style nit-pick:  Error!
The JVM doesn't really dramatize problems like that.  It tells you there was an error, and calmly describes the problem after a colon. "Error: " 8-)

(There are some "Error!" exclamations in java.xml and one has got into jdk.jfr, but they are unusual.)

You can tell me that nit-picking is NOT hyphenated if you like.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2527414361

From sgehwolf at openjdk.org  Fri Nov 14 13:15:18 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Nov 2025 13:15:18 GMT
Subject: RFR: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function [v5]
In-Reply-To: <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
 <LuZLP-0SS90YxuO34uozngdpQMt2ZgLNHQMSa1S_-wo=.2386fc6b-b24d-4cb0-8f47-44b36fa0d736@github.com>
Message-ID: <gX0-1gsNi4RVPLEOaYS6FyXXa6L4TLi_LDS2IWyokE8=.5edb1a53-ce95-407c-b957-31fe82408847@github.com>

On Wed, 12 Nov 2025 20:28:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
>> 
>> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
>> 
>> 
>> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
>> 
>> 
>> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
>> 
>> 
>> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
>> 
>> 
>> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
>> 
>> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
>> 
>> Thoughts?
>> 
>> **Testing:**
>> - [x] GHA
>> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix TestMisc for podman on cg v1 in rootless mode.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/28157#issuecomment-3532678185

From sgehwolf at openjdk.org  Fri Nov 14 13:15:19 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 14 Nov 2025 13:15:19 GMT
Subject: Integrated: 8370492: [Linux] Update cpu shares to cpu.weight mapping
 function
In-Reply-To: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
References: <V4xQPbmS4dV7p1pR5ughmfks3lDj_gSGOKmrae1CxY0=.9efd4547-71eb-4769-a9aa-63cc5a8bc28b@github.com>
Message-ID: <QLvbFlQI8t3MageG8gHw4_Sh7mGkUgIjDwiE44A3Ups=.f48a5d7c-cfeb-450d-bcd1-b43da0255568@github.com>

On Wed, 5 Nov 2025 18:13:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this change to the Linux container detection code updating the mapping function of cg v2 to most recent runtimes' implementation. OCI has been standardized with cgroup v1 in mind and there is a mapping function in place - implemented by container runtimes such as `runc` or `crun` - which map the passed `--cpu-shares` value on the engine's `run` command to the internal cgroup v2 `cpu.weight` interface file's values.
> 
> For runtimes lower than 1.23 (crun) and 1.3.2 (runc) the mapping function was (where `f(x)=<cpu.weight value>` and `x=<cpu-shares CLI value>`):
> 
> 
> f(x) = {(x - 2) \times 9999 + 1 \over 262142}
> 
> 
> This changed in `crun` >= 1.23 and `runc` >= 1.3.2 to:
> 
> 
> f(x)=10^{({{\log_{2}(x)}^2 \over 612} + {125 \over 612} \times \log_{2}(x) - {7 \over 34})}
> 
> 
> Therefore, we need to find the inverse of the new quadratic mapping function and use that over the inverse of the old mapping function. Since the input domain is `[2,262144]` for `--cpu-shares` mapping to `[1,10000]` for `cpu.weight` we can discount the negative exponent value as a possible solution.
> 
> Since there are production systems out there with those runtimes already I believe it's time to change the mapping function internal to the JDK to the new one in JDK 26. There is a chance that JDK 26 would run on old runtimes in a container using cgroup v2, resulting in wrong diagnostics. The chance of this happening will decrease over time.
> 
> Thoughts?
> 
> **Testing:**
> - [x] GHA
> - [x] `test/hotspot/jtreg/containers` and `test/jdk/jdk/internal/platform` on cgroup v1 (with an old runtime - code not affected) and on cgroup v2 with a new runtime. All tests passed.

This pull request has now been integrated.

Changeset: 5d65c23c
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d65c23cd99b72527dcfab9eb6da9510e7dc6330
Stats:     107 lines in 4 files changed: 90 ins; 0 del; 17 mod

8370492: [Linux] Update cpu shares to cpu.weight mapping function

Reviewed-by: cnorrbin, ayang, syan

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

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

From stuefe at openjdk.org  Fri Nov 14 13:20:00 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Nov 2025 13:20:00 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <42zufSBN8oVXdRilwv0ZasY8vAn9PajYHakHlhdGXZo=.a88d9d8d-357b-48de-ac07-f0b05f90b1c3@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
 <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
 <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>
 <mA2pkkPtDQSePh_g2csbK-BeOJDbQ90zAvjl56xamdg=.c881dc2c-e282-49bf-bad1-c840e538851c@github.com>
 <RzLeiXgH1FcR6WDQhn_HgCSWpzBbQPsK27Jlb4XguWQ=.091fd006-95e9-4112-a330-e6a1b654fc5b@github.com>
 <GL4Kvlvp-u7L54LXtKBxfNL01knDVCfcrINfg9T8tbo=.656bcc05-6ebd-420b-9c1b-234358639c05@github.com>
 <42zufSBN8oVXdRilwv0ZasY8vAn9PajYHakHlhdGXZo=.a88d9d8d-357b-48de-ac07-f0b05f90b1c3@github.com>
Message-ID: <NjNprwglzl5YZwrK1-BBouA-gikyzffoleHjvivZSYk=.1c538a0d-1d0b-4f00-97ab-5b39fa6d5a60@github.com>

On Fri, 14 Nov 2025 11:44:26 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> > We use ASAN in production to find real issues in sometimes large applications that may run a while before hitting an error.
> 
> TIL. I didn't know that anyone ran it in prod.
> 

Not in a production server. In production as in "trying to find errors in real production scenarios" where the JVM lives for a while. Think a long-running server app that only at certain points in its load hits errors. To do these tests, the app still needs to be somewhat reasonably fast. (like with JIT- most real-world scenarios are difficult to reproduce without a JIT, since you never even get there).

> I think (un)poisoning the whole header with one call is fine, probably preferable.
> 
> > Also, since we only access the header on os::malloc/realloc/free, we can move up the RAII unpoisoning helper to those functions and reduce the number of invocations from 16 to three call sites.
> 
> It does move the responsibility of unpoisoning from an internal detail to something the caller needs to be aware of and do. Not saying I'm against it, but I want to see what that looks like first.

True, but then, what is worse: sprinkling the code with so many unpoison calls - including the runtime overhead - or adding these calls to the three places where it matters, and that need to be aware of header logic anyway.

Side note: templates are powerful, but have a downside in that they make it hard for IDEs to analyze code. And to grapple with large code bases, a simple grep is not enough. For example, I saw that "Show Call Hierarchy" command in my IDE stopped working when invoked for `check_block_integrity` because `MallocHeader::resolve_checked_impl` is now templatized. We do this to handle both const and non-const pointers. In that case, is the benefit really worth it, compared to a simple const_cast?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2527473067

From stefank at openjdk.org  Fri Nov 14 13:56:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 14 Nov 2025 13:56:03 GMT
Subject: RFR: 8371894: Minor style fixes in AOT/CDS code
In-Reply-To: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
References: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
Message-ID: <5XugWPv5BUF86f8fhGD1DpcozcrXoTwyxUtBQWKh5wo=.1735e919-bd75-4580-9f43-b5fc7565dffb@github.com>

On Fri, 14 Nov 2025 11:07:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on [JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035) we have noticed some minor inconsistencies in code related to AOT and CDS which should be fixed.
> 
> Testing:
> * GHA

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28318#pullrequestreview-3465048102

From fparain at openjdk.org  Fri Nov 14 14:07:19 2025
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 14 Nov 2025 14:07:19 GMT
Subject: RFR: 8371860: Make non-public methods in java_lang_Class private
In-Reply-To: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
References: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
Message-ID: <9gRkuJiHKLhlWnuNtLGokTuEbpulh1Qz_pOJN-N8KBU=.bbceb485-06f2-4465-97d9-94e302040498@github.com>

On Thu, 13 Nov 2025 21:26:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this small cleanup for method declarations in java_lang_Class.
> Testing with tier1-4.

Marked as reviewed by fparain (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28308#pullrequestreview-3465104379

From mbaesken at openjdk.org  Fri Nov 14 14:07:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Nov 2025 14:07:21 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <ZT4iXoqROEqXtP7Tm_bdWzYsrCk_Hk1nt4Yyd8LzJ1Q=.79b0cbac-5ceb-46a0-bf49-b5c6dbdd0dc7@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <ZT4iXoqROEqXtP7Tm_bdWzYsrCk_Hk1nt4Yyd8LzJ1Q=.79b0cbac-5ceb-46a0-bf49-b5c6dbdd0dc7@github.com>
Message-ID: <hu7w2txJg16ZHHSnCL8YzApH_X8GEvlUI_eFpUTti-Y=.515a7b24-3b05-4dc5-887f-a4a47ba5019c@github.com>

On Fri, 14 Nov 2025 12:08:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   0 - terminate not needed
>
> src/java.base/unix/native/libjava/java_props_md.c line 395:
> 
>> 393:             sprops.cpu_isalist = strdup(list);
>> 394:         } else {
>> 395:             sprops.cpu_isalist = NULL;
> 
> Would you mind checking the code that puts this in a system property can tolerate NULL? I don't suppose sysinfo will fail here (unless you found a case?) but it would be good to confirm that it won't blow up somewhere else.

We do  PUTPROP here
https://github.com/openjdk/jdk/blob/5d65c23cd99b72527dcfab9eb6da9510e7dc6330/src/java.base/share/native/libjava/System.c#L164
with 3rd parameter == NULL in this case.
PUTPROP checks for this so I do not see issues with this
https://github.com/openjdk/jdk/blob/5d65c23cd99b72527dcfab9eb6da9510e7dc6330/src/java.base/share/native/libjava/System.c#L68

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2527633331

From coleenp at openjdk.org  Fri Nov 14 14:15:32 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Nov 2025 14:15:32 GMT
Subject: RFR: 8371860: Make non-public methods in java_lang_Class private
In-Reply-To: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
References: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
Message-ID: <pmQWRsQitew0JM8vrdOCF9OXvmYWH_Ay5e6Ip5_zGsw=.f299708c-03d0-4721-961a-6990ae485b29@github.com>

On Thu, 13 Nov 2025 21:26:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this small cleanup for method declarations in java_lang_Class.
> Testing with tier1-4.

Thanks Kim and Fred.

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

PR Comment: https://git.openjdk.org/jdk/pull/28308#issuecomment-3532986540

From coleenp at openjdk.org  Fri Nov 14 14:15:33 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 14 Nov 2025 14:15:33 GMT
Subject: Integrated: 8371860: Make non-public methods in java_lang_Class
 private
In-Reply-To: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
References: <OEcxC8BkZnpeKA-ktEC8DBkhDv5fAPNsF3-rALb8kn0=.5a6ab2d7-97a4-4232-81cb-87a14bfb3b26@github.com>
Message-ID: <M9l8sox4fXeorvSapNaBNVdXd783nRytCJkgWw7wSNI=.0ca9dced-6b70-4127-aa7d-84b6af8dfaf5@github.com>

On Thu, 13 Nov 2025 21:26:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this small cleanup for method declarations in java_lang_Class.
> Testing with tier1-4.

This pull request has now been integrated.

Changeset: 36daa265
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36daa2650d504b3cdc43c774601a6e5f9e9b2403
Stats:     25 lines in 2 files changed: 6 ins; 18 del; 1 mod

8371860: Make non-public methods in java_lang_Class private

Reviewed-by: kbarrett, fparain

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

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

From jsjolen at openjdk.org  Fri Nov 14 16:47:08 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 14 Nov 2025 16:47:08 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v20]
In-Reply-To: <NjNprwglzl5YZwrK1-BBouA-gikyzffoleHjvivZSYk=.1c538a0d-1d0b-4f00-97ab-5b39fa6d5a60@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <zzj6dju6AaFXzHOXlU7lnbuznSiR5eUlzEzz1sacBJw=.d751e6a8-7b1e-4134-b947-5a2427a24bbe@github.com>
 <3zTP99_68gLZyWIQTmPbvArKDqbUskNjmzrZ7wGTkos=.4c21d67b-05bb-43bc-a2b7-c20a087f350d@github.com>
 <8QB1jBQ7vx_DzACrKca9q8rAY4J7ltkA1xin_Q4ZCdw=.e0c1c416-d7c1-4c8f-a422-4b379b719bcb@github.com>
 <OLaNhWXzRkvfD4IXQSqU45tuZHsmgiO_b_jd2Nofamg=.6ade4b9a-7cc6-4a68-8ea1-716e6834988a@github.com>
 <aLePJiQiYcIAqR-mHWSpMd-Ob70x-4SSNEVj-TpgtXw=.73dba130-242f-41ed-a337-164afe57238d@github.com>
 <mA2pkkPtDQSePh_g2csbK-BeOJDbQ90zAvjl56xamdg=.c881dc2c-e282-49bf-bad1-c840e538851c@github.com>
 <RzLeiXgH1FcR6WDQhn_HgCSWpzBbQPsK27Jlb4XguWQ=.091fd006-95e9-4112-a330-e6a1b654fc5b@github.com>
 <GL4Kvlvp-u7L54LXtKBxfNL01knDVCfcrINfg9T8tbo=.656bcc05-6ebd-420b-9c1b-234358639c05@github.com>
 <42zufSBN8oVXdRilwv0ZasY8vAn9PajYHakHlhdGXZo=.a88d9d8d-357b-48de-ac07-f0b05f90b1c3@github.com>
 <NjNprwglzl5YZwrK1-BBouA-gikyzffoleH
 jvivZSYk=.1c538a0d-1d0b-4f00-97ab-5b39fa6d5a60@github.com>
Message-ID: <QsqQKRb_-jiJks5_JYe6DIcvLgt1Id1WWyNmNVF3VB0=.e6d20a2f-96e0-4de7-8666-abd2aefe2f3b@github.com>

On Fri, 14 Nov 2025 13:16:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> ... compared to a simple const_cast?

I saw that too a week or so ago. I thought the same, but I haven't prioritized putting up the PR.


> Not in a production server. In production as in "trying to find errors in real production scenarios" where the JVM lives for a while. Think a long-running server app that only at certain points in its load hits errors. To do these tests, the app still needs to be somewhat reasonably fast. (like with JIT- most real-world scenarios are difficult to reproduce without a JIT, since you never even get there).

Aha, yes, that's more reasonable and inline with my previous beliefs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2528211542

From dcubed at openjdk.org  Fri Nov 14 18:19:40 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 14 Nov 2025 18:19:40 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
Message-ID: <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>

On Fri, 14 Nov 2025 12:15:35 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed the test.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed lines in tests.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Added a comment to a boolean arg for enter()
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - 8366659: Fixed new lines.
>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94

Another crawl thru review of the test with more suggested changes.

I'll be doing one last round of commenting on the argument parsing stuff.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 124:

> 122: // launch resumer       enter threadLock
> 123: // <launch returns>     while !READY_TO_NOTIFY  resumer running
> 124: // delay 1-second         threadLock.wait(1)    wait for notify

We've deleted this sleep, so this line should change from:

// delay 1-second         threadLock.wait(1)    wait for notify

to:

// :                      threadLock.wait(1)    wait for notify

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 128:

> 126: // set READY_TO_NOTIFY  :
> 127: // threadLock.notify    wait finishes           :
> 128: // :                    reenter blocks          :

We added a sleep here, so this line should change from:

// :                    reenter blocks          :

to:

// : delay 200ms        reenter blocks          :

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 153:

> 151: //       thread allows the waiter thread to loop tightly here:
> 152: //         while !READY_TO_NOTIFY
> 153: //           threadLock.wait(1)

Please replace this note with the following:

// Note: sleep(200ms) here while holding the threadLock to allow the waiter thread's
// timed wait to finish before we attempt to suspend the waiter thread.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 212:

> 210:                 argsLeft--;
> 211:             }
> 212:             if (argsLeft == 0) {

Because of the addition of a mandatory argument (test case), argument parsing will
be more complicated. I need to mull on this a bit and I'll post another suggestion
after this round.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 237:

> 235: 
> 236:     public static void usage() {
> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");

The `N` argument is not optional so it should not be surrounded by `[` and `]`.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 239:

> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");
> 238:         System.err.println("where:");
> 239:         System.err.println("    N        ::= test case");

s/case/case: 1 | 2 | 3/

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 470:

> 468:                 }
> 469:                 try {
> 470:                     Thread.sleep(1000);

Please add something like this above the `sleep`:

// Delay for 1-second while holding the threadLock to force the
// resumer thread to block on entering the threadLock.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 552:

> 550:                 // wait for the waiter thread to block
> 551:                 logDebug("before contended enter wait");
> 552:                 int retCode = wait4ContendedEnter(waiter);

Since we are waiting here for ContendedEnter by the waiter thread, do we really
need the above `sleep(200)` or are we just being polite CPU resource wise?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 592:

> 590:                 }
> 591:                 try {
> 592:                     Thread.sleep(1000);

Please add something like this above the sleep:

// Delay for 1-second while holding the threadLock to force the
// resumer thread to block on entering the threadLock.

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

Marked as reviewed by dcubed (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3466061446
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528454607
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528465014
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528473772
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528423196
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528406725
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528408659
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528432284
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528443735
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528446025

From kvn at openjdk.org  Fri Nov 14 18:41:11 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Nov 2025 18:41:11 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
Message-ID: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>

On Thu, 13 Nov 2025 19:41:40 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - Error! Not a recording run
>> - Error! Not recording
>> - Recording ended successfully
>> - Error! Failed to end recording
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully
>> - Error! Not recording
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Document use of DiagnosticCommand

Comments.

src/hotspot/share/cds/aotMetaspace.cpp line 961:

> 959: }
> 960: 
> 961: bool AOTMetaspace::is_recording_preimage_static_archive() {

I think the name should be `preimage_static_archive_dumped()` to match field's name you accessing and check ` == 1` instead. The code in `AOTEndRecordingDCmd::execute()` will be more clear then.

src/hotspot/share/cds/aotMetaspace.cpp line 962:

> 960: 
> 961: bool AOTMetaspace::is_recording_preimage_static_archive() {
> 962:   if (CDSConfig::is_dumping_preimage_static_archive()) {

This is called after you already checked `CDSConfig::is_dumping_preimage_static_archive()`. May be replace the check with assert.

src/hotspot/share/cds/aotMetaspace.cpp line 973:

> 971:       return;
> 972:     }
> 973:   }

Add comment that this could be called from different threads and possibly concurrently: when JCMD requested it and normal call during VM exit. We should dump archive only once.

src/hotspot/share/services/diagnosticCommand.cpp line 996:

> 994:     output()->print_cr("Error! Not a recording run");
> 995:     return;
> 996:   }

First, is `output()` directed to VM's tty or somewhere else?

Second, I think you need to be more verbose in error. Maybe:

Error: AOT recording is not initiated. VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing.

src/hotspot/share/services/diagnosticCommand.cpp line 1000:

> 998:   if (!AOTMetaspace::is_recording_preimage_static_archive()) {
> 999:     output()->print_cr("Error! Not recording");
> 1000:     return;

This check is confusing because your error message is cryptic.
Actually I think you don't need any message here - it is not error. Use comment instead:

  // The other thread already initiated end of recording.

src/hotspot/share/services/diagnosticCommand.cpp line 1007:

> 1005:     output()->print_cr("Recording ended successfully");
> 1006:     return;
> 1007:   }

I think this should be reversed and message replaced with comment.

if (AOTMetaspace::is_recording_preimage_static_archive()) {
    // Other thread already dumped archive.
    return;
}
output()->print_cr("AOT recording ended successfully");

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

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3466124096
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528503476
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528453164
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528486742
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528446012
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528465285
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2528496380

From iklam at openjdk.org  Fri Nov 14 18:42:08 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Nov 2025 18:42:08 GMT
Subject: RFR: 8371874: AOTLinkedClassBulkLoader::preload_classes() should
 not allocate heap objects
In-Reply-To: <3cxj27LT4AdyylNIJ3TAUJBheo_dI6lw86GITeCdAR4=.54475eff-cc42-41d0-8b74-6595c79b3bd9@github.com>
References: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>
 <3cxj27LT4AdyylNIJ3TAUJBheo_dI6lw86GITeCdAR4=.54475eff-cc42-41d0-8b74-6595c79b3bd9@github.com>
Message-ID: <XZHxsLYvETPuCBy-CQE4RZqyYEzGBMnH6FR9unY_ZoU=.cca54a00-8912-42a6-9d1c-cbc01245c8c7@github.com>

On Fri, 14 Nov 2025 09:45:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> `AOTLinkedClassBulkLoader::preload_classes()` indirectly calls `java_lang_Class::restore_archived_mirror()` which can allocate an `int` array for the `init_lock`. However, the `init_lock` has already been allocated during AOT cache assembly :
>> 
>> 
>> java_lang_Class::create_scratch_mirror()
>> -> allocate_mirror()
>>   -> initialize_mirror_fields()
>>     -> set_init_lock()
>> 
>> 
>> So there's no need to allocate it again in the production run.
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @shipilev for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28315#issuecomment-3534079722

From kvn at openjdk.org  Fri Nov 14 18:43:20 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 14 Nov 2025 18:43:20 GMT
Subject: RFR: 8371894: Minor style fixes in AOT/CDS code
In-Reply-To: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
References: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
Message-ID: <K2rPGIdgXn0UwQpByHF7DLg_Oy3NiQvO0sHuumzMLfk=.5f8c7a34-8c19-4cca-9376-341359625fed@github.com>

On Fri, 14 Nov 2025 11:07:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on [JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035) we have noticed some minor inconsistencies in code related to AOT and CDS which should be fixed.
> 
> Testing:
> * GHA

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28318#pullrequestreview-3466287016

From iklam at openjdk.org  Fri Nov 14 18:45:16 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 14 Nov 2025 18:45:16 GMT
Subject: Integrated: 8371874: AOTLinkedClassBulkLoader::preload_classes()
 should not allocate heap objects
In-Reply-To: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>
References: <zhKxK-m9LsTzDJ96-g14_Cv_kUvtkoVf1y3XKd_N4PM=.5a04f84f-ee4b-4e95-826e-733d670e23a8@github.com>
Message-ID: <e0X2tZXx4UQFCEWAejYLawoFX79LnIm1ByjPWs6KK4U=.7c965e95-4482-4f2d-9f67-e8ad88d00855@github.com>

On Fri, 14 Nov 2025 04:43:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> `AOTLinkedClassBulkLoader::preload_classes()` indirectly calls `java_lang_Class::restore_archived_mirror()` which can allocate an `int` array for the `init_lock`. However, the `init_lock` has already been allocated during AOT cache assembly :
> 
> 
> java_lang_Class::create_scratch_mirror()
> -> allocate_mirror()
>   -> initialize_mirror_fields()
>     -> set_init_lock()
> 
> 
> So there's no need to allocate it again in the production run.

This pull request has now been integrated.

Changeset: 58b601ac
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58b601ac4250a455e3f25f8505ead8c130eba642
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8371874: AOTLinkedClassBulkLoader::preload_classes() should not allocate heap objects

Reviewed-by: shade, ayang

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

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

From dcubed at openjdk.org  Fri Nov 14 20:09:08 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 14 Nov 2025 20:09:08 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
Message-ID: <F7kLJwdxjybLzBlLCu1_prh6oDYNAFvzU36wTYrQfk8=.b689c8cc-962b-459b-8998-96ff5c229edb@github.com>

On Fri, 14 Nov 2025 17:54:05 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed the test.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 212:
> 
>> 210:                 argsLeft--;
>> 211:             }
>> 212:             if (argsLeft == 0) {
> 
> Because of the addition of a mandatory argument (test case), argument parsing will
> be more complicated. I need to mull on this a bit and I'll post another suggestion
> after this round.

I emailed you an updated version of the current test (v07) with a better
parser. Feel free to merge it in or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2528792374

From syan at openjdk.org  Sat Nov 15 04:09:01 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 15 Nov 2025 04:09:01 GMT
Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests
In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com>
Message-ID: <hkbUvD3G8QD-16jDxz6WF4glYdJioe21VMFm_3FWlSQ=.979554d6-1616-404f-9d20-7dfe7e733d24@github.com>

On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java.
> 
> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image.
> 
> Change has been verified locally on linux-x64 by run the all touched tests.

Looking for 2rd reviewer, since this PR touch files in hotspot directory.

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

PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3535663799

From iklam at openjdk.org  Sat Nov 15 04:17:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 15 Nov 2025 04:17:03 GMT
Subject: RFR: 8371894: Minor style fixes in AOT/CDS code
In-Reply-To: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
References: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
Message-ID: <yA49tTW0yWoosa8EdUDxsOhDYOPYvrcB9uKJ_BZ1sIY=.6863fbfc-148d-4763-97d3-e4272eef834d@github.com>

On Fri, 14 Nov 2025 11:07:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on [JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035) we have noticed some minor inconsistencies in code related to AOT and CDS which should be fixed.
> 
> Testing:
> * GHA

These are mostly whitespace changes and are in stable areas that are unlikely to be changed by future bug fixes, so there shouldn't be any impact on backporting .

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

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28318#pullrequestreview-3467642646

From iklam at openjdk.org  Sat Nov 15 04:57:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 15 Nov 2025 04:57:38 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
Message-ID: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>

During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):


try (var err = new PrintWriter(System.err);
      var out = new PrintWriter(System.out)) {
     out.println("Hello Confused World");
}


This has the side effect of closing the JVM's STDOUT.

When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.

If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.

This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.

The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.

The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.

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

Commit messages:
 - 8371944: AOT configuration is corrupted when app closes System.out

Changes: https://git.openjdk.org/jdk/pull/28335/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371944
  Stats: 130 lines in 6 files changed: 117 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28335/head:pull/28335

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

From kvn at openjdk.org  Sat Nov 15 05:37:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sat, 15 Nov 2025 05:37:02 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
Message-ID: <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>

On Sat, 15 Nov 2025 04:50:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
> 
> 
> try (var err = new PrintWriter(System.err);
>       var out = new PrintWriter(System.out)) {
>      out.println("Hello Confused World");
> }
> 
> 
> This has the side effect of closing the JVM's STDOUT.
> 
> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
> 
> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
> 
> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
> 
> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
> 
> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.

The fix seems fine for this case.

VM itself may open a lot of files for different logs (JFR, JIT logs, UL, etc). May VM close some before you open AOT file which could cause the same issue? Is it possible to track life time of such files to make sure we don't write into them after they are closed?

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3536035364

From jpai at openjdk.org  Sat Nov 15 05:54:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Nov 2025 05:54:10 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v15]
In-Reply-To: <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
Message-ID: <Er3qFR8JYTFAhF1_psZq2BM6jK21FCkJwUBRGJEoWtM=.4715db13-9841-4fb6-a2fd-0369f614f312@github.com>

On Fri, 14 Nov 2025 04:38:43 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

src/hotspot/os/bsd/os_bsd.hpp line 43:

> 41: // Bsd_OS defines the interface to Bsd operating systems
> 42: 
> 43: static constexpr int bsd_mmap_fd =

I don't have familiarity in this area, but looking at the man page of `mmap` on my local macos, it states this:


void *
mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset);
...
MAP_ANON          Map anonymous memory not associated with any specific file.  The offset argument is ignored.  Mac OS X specific: the file descriptor used for
                   creating MAP_ANON regions can be used to pass some Mach VM flags, and can be specified as -1 if no such flags are associated with the region.
                   Mach VM flags are defined in <mach/vm_statistics.h> and the ones that currently apply to mmap are:

                   VM_FLAGS_PURGABLE   to create Mach purgable (i.e. volatile) memory.

                   VM_MAKE_TAG(tag)    to associate an 8-bit tag with the region.
                   <mach/vm_statistics.h> defines some preset tags (with a VM_MEMORY_ prefix).  Users are encouraged to use tags between 240 and 255.  Tags are used
                   by tools such as vmmap(1) to help identify specific memory regions.


So this special value handling of `fd` value is only applicable if `MAP_ANON` is part of the `flags`.
Given this, should the name of constexpr be a bit more specific and the call sites, where this gets used, verify/assert that the flags indeed contains the `MAP_ANON` flag?
Plus, this is very macos specific, calling it `bsd_...` feels much more generic. Maybe we should consider naming it `macos_mmap_anon_fd`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2529614816

From stuefe at openjdk.org  Sat Nov 15 10:33:08 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 15 Nov 2025 10:33:08 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v15]
In-Reply-To: <Er3qFR8JYTFAhF1_psZq2BM6jK21FCkJwUBRGJEoWtM=.4715db13-9841-4fb6-a2fd-0369f614f312@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
 <Er3qFR8JYTFAhF1_psZq2BM6jK21FCkJwUBRGJEoWtM=.4715db13-9841-4fb6-a2fd-0369f614f312@github.com>
Message-ID: <Xa-B7pHQxPGC9gGx24UcJRCpALSpfHKdOM_1-Xr9A8w=.8cd42f4e-86c3-4684-a5e9-0eec244229df@github.com>

On Sat, 15 Nov 2025 05:51:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cleanup
>
> src/hotspot/os/bsd/os_bsd.hpp line 43:
> 
>> 41: // Bsd_OS defines the interface to Bsd operating systems
>> 42: 
>> 43: static constexpr int bsd_mmap_fd =
> 
> I don't have familiarity in this area, but looking at the man page of `mmap` on my local macos, it states this:
> 
> 
> void *
> mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset);
> ...
> MAP_ANON          Map anonymous memory not associated with any specific file.  The offset argument is ignored.  Mac OS X specific: the file descriptor used for
>                    creating MAP_ANON regions can be used to pass some Mach VM flags, and can be specified as -1 if no such flags are associated with the region.
>                    Mach VM flags are defined in <mach/vm_statistics.h> and the ones that currently apply to mmap are:
> 
>                    VM_FLAGS_PURGABLE   to create Mach purgable (i.e. volatile) memory.
> 
>                    VM_MAKE_TAG(tag)    to associate an 8-bit tag with the region.
>                    <mach/vm_statistics.h> defines some preset tags (with a VM_MEMORY_ prefix).  Users are encouraged to use tags between 240 and 255.  Tags are used
>                    by tools such as vmmap(1) to help identify specific memory regions.
> 
> 
> So this special value handling of `fd` value is only applicable if `MAP_ANON` is part of the `flags`.
> Given this, should the name of constexpr be a bit more specific and the call sites, where this gets used, verify/assert that the flags indeed contains the `MAP_ANON` flag?
> Plus, this is very macos specific, calling it `bsd_...` feels much more generic. Maybe we should consider naming it `macos_mmap_anon_fd`?

@jaikiran If `MAP_ANON` is not set, a file descriptor will be given. Contract for MAP_ANON (or MAP_ANONYMOUS on Linux).

About the bsd.. naming:

I think this is okay. The source split between xxBSD and Mac is long overdue. I think there is (was?) someone from the FreeBSD foundation working on it. 

That said, I think this should not be a global constant but live in the os::BSD namespace/class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2529763594

From stuefe at openjdk.org  Sat Nov 15 10:45:14 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 15 Nov 2025 10:45:14 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v15]
In-Reply-To: <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
Message-ID: <hB6XBBrC5bZtI8DX6h1-B_KMigQK40jVa3SEntNpyVg=.8c89a364-d653-4658-93d6-d416ddbdddd2@github.com>

On Fri, 14 Nov 2025 04:38:43 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

What is the benefit of just tagging all mappings the JVM process does in HotSpot somewhat indiscriminately as "java"?

Would it not typically be just a list of, well, all anonymous mappings done with mmap by the hotspot library? But then, it leaves other mappings out somewhat arbitrarily: mmaps from JDK libraries (e.g. NIO, zlib), thread stacks, or mmaps done with a backing file (e.g. if heap is created on NVRAM).

Note that we added a diagnostic command back in 2021 (https://bugs.openjdk.org/browse/JDK-8318636, `System.map`). That command shows all mappings in great detail. It was ported to MacOS (https://bugs.openjdk.org/browse/JDK-8319875) and should show a complete list of all memory mappings, decorated with NMT tags. So you would see all mappings and what they were created for (e.g. you see Java Heap, Code cache, Metaspace, Thread stacks etc). Would this not already give us more detail than this tagging would provides us with?

src/hotspot/os/bsd/os_bsd.hpp line 43:

> 41: // Bsd_OS defines the interface to Bsd operating systems
> 42: 
> 43: static constexpr int bsd_mmap_fd =

@nityarai08 Can this live in os::Bsd?

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

PR Review: https://git.openjdk.org/jdk/pull/27868#pullrequestreview-3467925797
PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2529764035

From jpai at openjdk.org  Sat Nov 15 11:39:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 15 Nov 2025 11:39:06 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v15]
In-Reply-To: <Xa-B7pHQxPGC9gGx24UcJRCpALSpfHKdOM_1-Xr9A8w=.8cd42f4e-86c3-4684-a5e9-0eec244229df@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
 <Er3qFR8JYTFAhF1_psZq2BM6jK21FCkJwUBRGJEoWtM=.4715db13-9841-4fb6-a2fd-0369f614f312@github.com>
 <Xa-B7pHQxPGC9gGx24UcJRCpALSpfHKdOM_1-Xr9A8w=.8cd42f4e-86c3-4684-a5e9-0eec244229df@github.com>
Message-ID: <_5s6rTKQFmxHZHrBuvpTRzKy35lX45_TwBrymm7uxIU=.df72a0f6-a15f-41f2-98ef-60b3677f7d30@github.com>

On Sat, 15 Nov 2025 10:29:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> src/hotspot/os/bsd/os_bsd.hpp line 43:
>> 
>>> 41: // Bsd_OS defines the interface to Bsd operating systems
>>> 42: 
>>> 43: static constexpr int bsd_mmap_fd =
>> 
>> I don't have familiarity in this area, but looking at the man page of `mmap` on my local macos, it states this:
>> 
>> 
>> void *
>> mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset);
>> ...
>> MAP_ANON          Map anonymous memory not associated with any specific file.  The offset argument is ignored.  Mac OS X specific: the file descriptor used for
>>                    creating MAP_ANON regions can be used to pass some Mach VM flags, and can be specified as -1 if no such flags are associated with the region.
>>                    Mach VM flags are defined in <mach/vm_statistics.h> and the ones that currently apply to mmap are:
>> 
>>                    VM_FLAGS_PURGABLE   to create Mach purgable (i.e. volatile) memory.
>> 
>>                    VM_MAKE_TAG(tag)    to associate an 8-bit tag with the region.
>>                    <mach/vm_statistics.h> defines some preset tags (with a VM_MEMORY_ prefix).  Users are encouraged to use tags between 240 and 255.  Tags are used
>>                    by tools such as vmmap(1) to help identify specific memory regions.
>> 
>> 
>> So this special value handling of `fd` value is only applicable if `MAP_ANON` is part of the `flags`.
>> Given this, should the name of constexpr be a bit more specific and the call sites, where this gets used, verify/assert that the flags indeed contains the `MAP_ANON` flag?
>> Plus, this is very macos specific, calling it `bsd_...` feels much more generic. Maybe we should consider naming it `macos_mmap_anon_fd`?
>
> @jaikiran If `MAP_ANON` is not set, a file descriptor will be given. Contract for MAP_ANON (or MAP_ANONYMOUS on Linux).
> 
> About the bsd.. naming:
> 
> I think this is okay. The source split between xxBSD and Mac is long overdue. I think there is (was?) someone from the FreeBSD foundation working on it. 
> 
> That said, I think this should not be a global constant but live in the os::BSD namespace/class.

Hello Thomas, 

> If MAP_ANON is not set, a file descriptor will be given. Contract for MAP_ANON (or MAP_ANONYMOUS on Linux).

I was thinking about call sites like this https://github.com/openjdk/jdk/pull/27868/files#diff-1f93205c2e57bee432f8fb7a0725ba1dfdbe5b901ac63010ea0b43922e34ac12R1692 :

char* addr = (char*)::mmap(requested_addr, bytes, PROT_NONE, flags, bsd_mmap_fd, 0);

where the `flags` may be defined a few lines away and it may not be easy to guarantee/spot that those `flags` have `MAP_ANON`. Using this new `bsd_mmap_fd` in such places without additional checks on `flags`, I suspect, might lead to subtle issues (if for example, those flags are updated in future)? I don't have any prior knowledge of the code that's being updated here, so my concern may not be practical after all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2529831333

From kbarrett at openjdk.org  Sun Nov 16 01:03:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 16 Nov 2025 01:03:06 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v15]
In-Reply-To: <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
Message-ID: <i-UB9xo58Yqc9lY5EJbHQpzODOqGXCZMO7Vym6ogAxs=.3f64c94b-c1c0-48e1-8f54-067d9b786b62@github.com>

On Fri, 14 Nov 2025 04:38:43 GMT, Nityanand Rai <duke at openjdk.org> wrote:

>> Add VM_MEMORY_JAVA tag to mmap calls in os_bsd.cpp for better memory tracking of java process on macOs
>
> Nityanand Rai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup

test/hotspot/gtest/testutils.cpp line 70:

> 68: }
> 69: 
> 70: #if APPLE_MEMORY_TAGGING_AVAILABLE

Why is this stuff in testutils, rather than just being co-located with the one using test?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27868#discussion_r2530716514

From kbarrett at openjdk.org  Sun Nov 16 01:17:16 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 16 Nov 2025 01:17:16 GMT
Subject: RFR: 8370254: Add VM_MEMORY_JAVA mmap tag to MacOS mmap calls
 [v15]
In-Reply-To: <hB6XBBrC5bZtI8DX6h1-B_KMigQK40jVa3SEntNpyVg=.8c89a364-d653-4658-93d6-d416ddbdddd2@github.com>
References: <3oC_tXLUghBm6DYolHcOZf5ne2kmFbeK2xmEe08GB6w=.72a04750-20bc-4ef7-9d2c-5f411b2e70ef@github.com>
 <UtfL3DsvEaijgDj1RF8pveOTgmgOmjruw4s8rnePmUE=.3c04a798-fbba-437e-9452-38d8e095fbb8@github.com>
 <hB6XBBrC5bZtI8DX6h1-B_KMigQK40jVa3SEntNpyVg=.8c89a364-d653-4658-93d6-d416ddbdddd2@github.com>
Message-ID: <quWg8WAQiTZ1OuLkaye5JxsuxQhYDnNVDz-yU5-Zey4=.95855109-2926-468f-89fd-5bd145049540@github.com>

On Sat, 15 Nov 2025 10:42:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> What is the benefit of just tagging all mappings the JVM process does in HotSpot somewhat indiscriminately as "java"?

I was wondering much the same thing as @tstuefe , but with less knowledge than him about what we already have.

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

PR Comment: https://git.openjdk.org/jdk/pull/27868#issuecomment-3537265187

From alanb at openjdk.org  Sun Nov 16 17:31:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 16 Nov 2025 17:31:19 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <lT0-ac-y31gy5-Z38R1iRu5CWazTSSEDFdw96m3GM_w=.d9e43c30-f60d-4240-81c8-89d47243e5c8@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

Thanks for checking that cpu_isalist == NULL is okay, the update to java_props_md.c looks okay to me.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28317#pullrequestreview-3470333746

From dholmes at openjdk.org  Mon Nov 17 01:05:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Nov 2025 01:05:07 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <Vxb5s3-a97MSfXsESNA5FmTP0qKBKZ_jYuRDW183p20=.8c2cf58d-0179-472d-b023-5671ac537bb7@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

I think this is completely unnecessary - `sysinfo`  on Linux can't really fail, the only error possible is EFAULT if you pass a bad pointer for the struct - so don't do that.

Replacing numbers with words in the logging could break external parsing scripts.

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

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3539576209

From syan at openjdk.org  Mon Nov 17 02:45:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 02:45:45 GMT
Subject: RFR: 8371769: TestMemoryInvisibleParent.java fails
 java.nio.file.AccessDeniedException [v2]
In-Reply-To: <zFcxfyZig1unRmDYC7AIRB5KOby3rrp6TAbAkXnp6z8=.6bbd6a2a-60e7-4d08-9e13-aaf8dca7dc43@github.com>
References: <zFcxfyZig1unRmDYC7AIRB5KOby3rrp6TAbAkXnp6z8=.6bbd6a2a-60e7-4d08-9e13-aaf8dca7dc43@github.com>
Message-ID: <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com>

> Hi all,
> 
> Test test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java fails when run with non-root user. Test will try to write file /sys/fs/cgroup/memory/hidden-parent-TestMemoryInvisibleParent26/memory.limit_in_bytes, and this will make non-root user report java.nio.file.AccessDeniedException. So I think we should skip this test when user is not root.
> 
> This PR also add prefix indent for a try block, but do not touch the original logic.
> 
> Change has been verified locally on linux-aarch64 with non-root user.

SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into jbs8371769
 - 8371769: TestMemoryInvisibleParent.java fails java.nio.file.AccessDeniedException

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28286/files
  - new: https://git.openjdk.org/jdk/pull/28286/files/a6ee85df..2837903c

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

  Stats: 4767 lines in 126 files changed: 2581 ins; 1305 del; 881 mod
  Patch: https://git.openjdk.org/jdk/pull/28286.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28286/head:pull/28286

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

From duke at openjdk.org  Mon Nov 17 05:22:19 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Mon, 17 Nov 2025 05:22:19 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v9]
In-Reply-To: <eWKZXOL8TIRztsYpQexPdc2t97yrXllPVwLWnojjqnM=.1acf8e34-2e7e-48bb-a3cb-bf4a2706f106@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <eWKZXOL8TIRztsYpQexPdc2t97yrXllPVwLWnojjqnM=.1acf8e34-2e7e-48bb-a3cb-bf4a2706f106@github.com>
Message-ID: <nrJVppYERRrcm2B43nrL3nic8qJ2Zrz-zmIjuJtt2zA=.b3420806-a56c-476b-8224-91e6dd3efd2e@github.com>

On Fri, 17 Oct 2025 22:25:44 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

>> Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail.
>> 
>> Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior.
>
> Benjamin Peterson 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 15 additional commits since the last revision:
> 
>  - add test showing loading symlinked libraries with various combinations
>  - revert dll_load fix
>  - Merge branch 'master' into nativelibraries-fix
>  - add cast
>  - use os::malloc
>  - Merge branch 'master' into nativelibraries-fix
>  - fix compilation
>  - fix grammar
>  - add dot in os::dll_load rather than NativeLibraries.java
>  - Merge remote-tracking branch 'origin/master' into nativelibraries-fix
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/ab30fa02...09de5608

Did any thoughts come back from security?

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

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3540027643

From alanb at openjdk.org  Mon Nov 17 07:13:14 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 17 Nov 2025 07:13:14 GMT
Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v9]
In-Reply-To: <nrJVppYERRrcm2B43nrL3nic8qJ2Zrz-zmIjuJtt2zA=.b3420806-a56c-476b-8224-91e6dd3efd2e@github.com>
References: <f49PHIpcw05j1O5KpVLwxWq7eHftNjLKkVG2830sKBc=.2bbf5b02-e06a-41a9-bf2b-d8ea671a6341@github.com>
 <eWKZXOL8TIRztsYpQexPdc2t97yrXllPVwLWnojjqnM=.1acf8e34-2e7e-48bb-a3cb-bf4a2706f106@github.com>
 <nrJVppYERRrcm2B43nrL3nic8qJ2Zrz-zmIjuJtt2zA=.b3420806-a56c-476b-8224-91e6dd3efd2e@github.com>
Message-ID: <KsNAlCjQvFJi-z3Q-BnocCg4ELXxeFRFjyugtdnh4wU=.2d842d82-349c-472a-901f-922accecef50@github.com>

On Mon, 17 Nov 2025 05:19:31 GMT, Benjamin Peterson <duke at openjdk.org> wrote:

> Did any thoughts come back from security?

Still discussing. Sorry I cannot share the details here.

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

PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3540282068

From azafari at openjdk.org  Mon Nov 17 08:02:02 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 17 Nov 2025 08:02:02 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap [v2]
In-Reply-To: <FzBoq9wMeJH74r0Af2GQv2GWGmc7oss5pANdWVWrmoM=.4d398a26-dc06-4bd0-b43f-b7519328d67e@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
 <FzBoq9wMeJH74r0Af2GQv2GWGmc7oss5pANdWVWrmoM=.4d398a26-dc06-4bd0-b43f-b7519328d67e@github.com>
Message-ID: <2t5LbOzGTzDCbhAa-09JFPLuzoUigCvW7jtjcfF74AY=.97c985ac-fe5b-4676-a93d-e1da6373333c@github.com>

On Fri, 14 Nov 2025 10:51:23 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.
>> 
>> Testing: GHA
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comment

Thanks. Looks good to me.

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28285#pullrequestreview-3471424815

From phubner at openjdk.org  Mon Nov 17 08:48:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 17 Nov 2025 08:48:03 GMT
Subject: RFR: 8371607: Remove GCSharedStringsDuringDumpWb.java after
 JDK-8362561
In-Reply-To: <psPn6mVMddsFBn-buaW6bthXEEY9zV0rtXCM0SfV43A=.a6536cd0-a6d5-4e85-910f-f10e9e59ef1a@github.com>
References: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
 <psPn6mVMddsFBn-buaW6bthXEEY9zV0rtXCM0SfV43A=.a6536cd0-a6d5-4e85-910f-f10e9e59ef1a@github.com>
Message-ID: <zK7llcA8WF7FIP-mjKaFmOjB1sn5loeeW2HnUgEX5dA=.a094c270-f652-4ee4-9144-fb441c1b0994@github.com>

On Fri, 14 Nov 2025 10:10:50 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) removed `runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java` which was the only place where `GCSharedStringsDuringDumpWb.java` was used. Therefore, `GCSharedStringsDuringDumpWb.java` should be cleaned up.
>> 
>> Testing: tiers 1-3 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).
>
> Marked as reviewed by ayang (Reviewer).

Thanks for the reviews, @albertnetymk @jsikstro.

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

PR Comment: https://git.openjdk.org/jdk/pull/28300#issuecomment-3540580837

From phubner at openjdk.org  Mon Nov 17 08:48:05 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 17 Nov 2025 08:48:05 GMT
Subject: RFR: 8371607: Remove GCSharedStringsDuringDumpWb.java after
 JDK-8362561
In-Reply-To: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
References: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
Message-ID: <MDlChE-iQvwr7NOFo4cdysbexLdSxY5uZw_Y3WgxIQ8=.568520ab-6667-4bfe-8c3c-e7a77f378ecd@github.com>

On Thu, 13 Nov 2025 16:49:32 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) removed `runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java` which was the only place where `GCSharedStringsDuringDumpWb.java` was used. Therefore, `GCSharedStringsDuringDumpWb.java` should be cleaned up.
> 
> Testing: tiers 1-3 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

Good morning to me, I got the command wrong.

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

PR Comment: https://git.openjdk.org/jdk/pull/28300#issuecomment-3540584114

From duke at openjdk.org  Mon Nov 17 08:48:06 2025
From: duke at openjdk.org (duke)
Date: Mon, 17 Nov 2025 08:48:06 GMT
Subject: RFR: 8371607: Remove GCSharedStringsDuringDumpWb.java after
 JDK-8362561
In-Reply-To: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
References: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
Message-ID: <yk9NjVQlbwMgzPnZUrvMycwalbc56kdS_655mbTSaeg=.3d7d47f8-2af4-4304-856e-fab3bfd80844@github.com>

On Thu, 13 Nov 2025 16:49:32 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) removed `runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java` which was the only place where `GCSharedStringsDuringDumpWb.java` was used. Therefore, `GCSharedStringsDuringDumpWb.java` should be cleaned up.
> 
> Testing: tiers 1-3 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

@Arraying 
Your change (at version 20d6f71a3cb3850b8c44f153f8588992f3bd3c18) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28300#issuecomment-3540587849

From jsikstro at openjdk.org  Mon Nov 17 08:54:25 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 17 Nov 2025 08:54:25 GMT
Subject: RFR: 8371894: Minor style fixes in AOT/CDS code
In-Reply-To: <yA49tTW0yWoosa8EdUDxsOhDYOPYvrcB9uKJ_BZ1sIY=.6863fbfc-148d-4763-97d3-e4272eef834d@github.com>
References: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
 <yA49tTW0yWoosa8EdUDxsOhDYOPYvrcB9uKJ_BZ1sIY=.6863fbfc-148d-4763-97d3-e4272eef834d@github.com>
Message-ID: <5am3crznnPJ8uCC7wuPrtqP5k3Spjyen0Bk4M7XLZOU=.a3d478cf-8c0f-4888-a1db-9b244986ea14@github.com>

On Sat, 15 Nov 2025 04:14:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Hello,
>> 
>> While working on [JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035) we have noticed some minor inconsistencies in code related to AOT and CDS which should be fixed.
>> 
>> Testing:
>> * GHA
>
> These are mostly whitespace changes and are in stable areas that are unlikely to be changed by future bug fixes, so there shouldn't be any impact on backporting .

Thank you for the reviews everyone. Sounds good @iklam.

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

PR Comment: https://git.openjdk.org/jdk/pull/28318#issuecomment-3540605697

From jsikstro at openjdk.org  Mon Nov 17 08:54:27 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 17 Nov 2025 08:54:27 GMT
Subject: Integrated: 8371894: Minor style fixes in AOT/CDS code
In-Reply-To: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
References: <thoN_ZOsLZEN-3lAr_6vvHxJ-ZUUR2cku1sEenG0bJc=.d621ffde-de71-48a0-bbc8-3db14e7f6c5a@github.com>
Message-ID: <faBc9zCuRY4B1lX7TBn2VE4mJTHSEAkTO3wVpKjVSLA=.b6d03465-ad99-437e-ab6d-3900b3271e9e@github.com>

On Fri, 14 Nov 2025 11:07:19 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on [JDK-8326035](https://bugs.openjdk.org/browse/JDK-8326035) we have noticed some minor inconsistencies in code related to AOT and CDS which should be fixed.
> 
> Testing:
> * GHA

This pull request has now been integrated.

Changeset: d032b28d
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d032b28d9d042a36f5163b079151643bb49294e9
Stats:     30 lines in 4 files changed: 3 ins; 4 del; 23 mod

8371894: Minor style fixes in AOT/CDS code

Reviewed-by: stefank, kvn, iklam

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

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

From jsjolen at openjdk.org  Mon Nov 17 09:09:22 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 17 Nov 2025 09:09:22 GMT
Subject: RFR: 8371779: Replace MemTagBitmap with ResourceBitMap [v2]
In-Reply-To: <FzBoq9wMeJH74r0Af2GQv2GWGmc7oss5pANdWVWrmoM=.4d398a26-dc06-4bd0-b43f-b7519328d67e@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
 <FzBoq9wMeJH74r0Af2GQv2GWGmc7oss5pANdWVWrmoM=.4d398a26-dc06-4bd0-b43f-b7519328d67e@github.com>
Message-ID: <Gu2tEV-Zk7nwzFyutCaem_yJp4-M1u7rb4KRFHTl1Ec=.6ce629b9-f3d2-4271-a9e9-5255465fe008@github.com>

On Fri, 14 Nov 2025 10:51:23 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.
>> 
>> Testing: GHA
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comment

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28285#issuecomment-3540678988

From jsjolen at openjdk.org  Mon Nov 17 09:09:23 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 17 Nov 2025 09:09:23 GMT
Subject: Integrated: 8371779: Replace MemTagBitmap with ResourceBitMap
In-Reply-To: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
References: <3xylE1EXnfoYBUbJCCj5M76g1q1TuGx9jF1YDYvkMFI=.b658d2cb-7f75-4895-8203-8542298f8b3a@github.com>
Message-ID: <zmXhnxVoi9_1eGCRCzTjnZ_4dM52jfft8CUL5EKlcvs=.c7463af0-9aa3-42bb-98c2-47afd267d32a@github.com>

On Thu, 13 Nov 2025 09:16:34 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> We don't really need our own bitmap implementation and can instead use the utility `ResourceBitMap`. This is a nice cleanup, imho.
> 
> Testing: GHA

This pull request has now been integrated.

Changeset: 970533d4
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/970533d41d3d1b4ebe12868c85579d37b3b23655
Stats:     69 lines in 2 files changed: 4 ins; 59 del; 6 mod

8371779: Replace MemTagBitmap with ResourceBitMap

Reviewed-by: azafari, phubner

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

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

From aph at openjdk.org  Mon Nov 17 09:36:36 2025
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 17 Nov 2025 09:36:36 GMT
Subject: RFR: 8261837: SIGSEGV in ciVirtualCallTypeData::translate_from
 [v5]
In-Reply-To: <a_Y4oRc1DW_Wisxv6frGEb3pBUHNvJeKfVg75A54jn0=.87a37b9e-ce0a-4cc2-8f4a-857518c6227e@github.com>
References: <02JzN66pkbsxQOjb6-fbHPf4Y5p0d1jIPERz80WXv7Q=.b507b97f-2625-4b9c-8b65-dac0a609251e@github.com>
 <a_Y4oRc1DW_Wisxv6frGEb3pBUHNvJeKfVg75A54jn0=.87a37b9e-ce0a-4cc2-8f4a-857518c6227e@github.com>
Message-ID: <hLNFfp9MPpN6JOm9GegBkaQNDNRAbbISFjBeURj7Vi0=.7ee62874-7926-4667-b1b8-b69e8c73ec58@github.com>

On Thu, 23 Nov 2023 00:34:20 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Type profiling code based on the x86 implementation uses XOR to check if the MDO value matches the klass, then later stores that XORed value into the MDO if the MDO value was 0.  However, there is a race here if we reload the MDO value to check for 0, resulting in storing OBJ_KLASS XOR MDO_KLASS back to the MDO.
>> 
>> I took a stab at riscv, but I don't have a way to test it.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   riscv patch from Fei Yang <fyang at openjdk.org>

src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 3658:

> 3656: #endif
> 3657:       // atomic update to prevent overwriting Klass* with 0
> 3658:       __ lock();

One thing I'm curious about: why is the locked update only here on x86, and not in any other port?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16750#discussion_r2533363164

From phubner at openjdk.org  Mon Nov 17 09:49:12 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 17 Nov 2025 09:49:12 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
In-Reply-To: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
Message-ID: <-KW-vofIJBimNdTprQQlBV05yDIQlniq6Q1pSTO1CVU=.ffbdc741-2a74-423b-9503-03918ba72ef5@github.com>

On Thu, 6 Nov 2025 08:51:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
> 
> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> 
> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
> 
> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # CreateCoredumpOnCrash turned off, no core file dumped
> 
> **Scenario 2: `get_core_path` errors**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core path is unknown, trying core.1552174 (may not exist)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: core.1552174 (may not exist)
> 
> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/foo/bar/core.1555400)
> 
> **Scenario 4: the resource limit for core dumps could not be determined**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but couldn't deduce rlim, trying /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #  [...]
>> # Core dump will be written. Default location: /tmp/cores/core.%e.1560382.%h.%t (may not exist)
> 
> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # A fatal er...

@tstuefe since you raised the RFE, would you mind taking a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/28174#issuecomment-3540843605

From aartemov at openjdk.org  Mon Nov 17 13:50:39 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 17 Nov 2025 13:50:39 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <F7kLJwdxjybLzBlLCu1_prh6oDYNAFvzU36wTYrQfk8=.b689c8cc-962b-459b-8998-96ff5c229edb@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
 <F7kLJwdxjybLzBlLCu1_prh6oDYNAFvzU36wTYrQfk8=.b689c8cc-962b-459b-8998-96ff5c229edb@github.com>
Message-ID: <n9Zhw7amVqdxFuJxxiZQPoD3M-zo1nEkH2aafiiLYsA=.5fa6eccb-dcfb-49be-b368-bcd01ad666ce@github.com>

On Fri, 14 Nov 2025 20:05:31 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 212:
>> 
>>> 210:                 argsLeft--;
>>> 211:             }
>>> 212:             if (argsLeft == 0) {
>> 
>> Because of the addition of a mandatory argument (test case), argument parsing will
>> be more complicated. I need to mull on this a bit and I'll post another suggestion
>> after this round.
>
> I emailed you an updated version of the current test (v07) with a better
> parser. Feel free to merge it in or not.

Thanks, I added your parsing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534135964

From aartemov at openjdk.org  Mon Nov 17 13:50:38 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 17 Nov 2025 13:50:38 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
Message-ID: <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>

On Fri, 14 Nov 2025 18:07:27 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed the test.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed lines in tests.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Added a comment to a boolean arg for enter()
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - 8366659: Fixed new lines.
>>  - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ff851de8...2ac18b94
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 124:
> 
>> 122: // launch resumer       enter threadLock
>> 123: // <launch returns>     while !READY_TO_NOTIFY  resumer running
>> 124: // delay 1-second         threadLock.wait(1)    wait for notify
> 
> We've deleted this sleep, so this line should change from:
> 
> // delay 1-second         threadLock.wait(1)    wait for notify
> 
> to:
> 
> // :                      threadLock.wait(1)    wait for notify

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 128:
> 
>> 126: // set READY_TO_NOTIFY  :
>> 127: // threadLock.notify    wait finishes           :
>> 128: // :                    reenter blocks          :
> 
> We added a sleep here, so this line should change from:
> 
> // :                    reenter blocks          :
> 
> to:
> 
> // : delay 200ms        reenter blocks          :

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 153:
> 
>> 151: //       thread allows the waiter thread to loop tightly here:
>> 152: //         while !READY_TO_NOTIFY
>> 153: //           threadLock.wait(1)
> 
> Please replace this note with the following:
> 
> // Note: sleep(200ms) here while holding the threadLock to allow the waiter thread's
> // timed wait to finish before we attempt to suspend the waiter thread.

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 237:
> 
>> 235: 
>> 236:     public static void usage() {
>> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");
> 
> The `N` argument is not optional so it should not be surrounded by `[` and `]`.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 239:
> 
>> 237:         System.err.println("Usage: " + AGENT_LIB + " [N][-p][time_max]");
>> 238:         System.err.println("where:");
>> 239:         System.err.println("    N        ::= test case");
> 
> s/case/case: 1 | 2 | 3/

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 470:
> 
>> 468:                 }
>> 469:                 try {
>> 470:                     Thread.sleep(1000);
> 
> Please add something like this above the `sleep`:
> 
> // Delay for 1-second while holding the threadLock to force the
> // resumer thread to block on entering the threadLock.

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 552:
> 
>> 550:                 // wait for the waiter thread to block
>> 551:                 logDebug("before contended enter wait");
>> 552:                 int retCode = wait4ContendedEnter(waiter);
> 
> Since we are waiting here for ContendedEnter by the waiter thread, do we really
> need the above `sleep(200)` or are we just being polite CPU resource wise?

Maybe I do not fully understand the question, but isn't it what differentiates test case 2 from test case 3?

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 592:
> 
>> 590:                 }
>> 591:                 try {
>> 592:                     Thread.sleep(1000);
> 
> Please add something like this above the sleep:
> 
> // Delay for 1-second while holding the threadLock to force the
> // resumer thread to block on entering the threadLock.

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534136973
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534137344
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534137633
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534135509
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534135744
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534138176
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534136258
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2534136725

From aartemov at openjdk.org  Mon Nov 17 13:50:30 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Mon, 17 Nov 2025 13:50:30 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/2ac18b94..28725284

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=07-08

  Stats: 81 lines in 1 file changed: 49 ins; 7 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From phubner at openjdk.org  Mon Nov 17 14:09:44 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 17 Nov 2025 14:09:44 GMT
Subject: Integrated: 8371607: Remove GCSharedStringsDuringDumpWb.java after
 JDK-8362561
In-Reply-To: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
References: <6UlE2S9fSTaWYaBfHGf7JYmM6F1eCK-tgb1W_07PoMI=.f0956008-27d5-4d46-b370-006c15ec39d7@github.com>
Message-ID: <FMw8JqRuJEO33XB57GUAxCgWOp9tnvoucUiIsiRYA6A=.526685d6-27d0-4513-853e-a80a94bcee9d@github.com>

On Thu, 13 Nov 2025 16:49:32 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> [JDK-8362561](https://bugs.openjdk.org/browse/JDK-8362561) removed `runtime/cds/appcds/javaldr/GCSharedStringsDuringDump.java` which was the only place where `GCSharedStringsDuringDumpWb.java` was used. Therefore, `GCSharedStringsDuringDumpWb.java` should be cleaned up.
> 
> Testing: tiers 1-3 Linux (x64, AArch64), macOS (x64, AArch64), Windows (x64).

This pull request has now been integrated.

Changeset: 6385c663
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6385c663dc6ce892c23bc9208e1ffe24fa78ccd7
Stats:     45 lines in 1 file changed: 0 ins; 45 del; 0 mod

8371607: Remove GCSharedStringsDuringDumpWb.java after JDK-8362561

Reviewed-by: ayang, jsikstro

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

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

From syan at openjdk.org  Mon Nov 17 14:37:18 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 17 Nov 2025 14:37:18 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small on
 linux-aarch64
Message-ID: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>

Hi all,

On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:


page_size = 64K
_java_thread_min_stack_allowed = 72K
_stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
_stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
_stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
_stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
_java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K


Change has been verified locally both on linux-x64 and linux-aarch64.

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

Commit messages:
 - 8371948: TestStackOverflowDuringInit.java fails xss too small on linux-aarch64

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

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

From dcubed at openjdk.org  Mon Nov 17 19:30:43 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 17 Nov 2025 19:30:43 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
Message-ID: <A20ZLkmDxZHTscHTY9iVwaO1jEX0n_jK4dvFIC1LsPI=.c7a1efb4-ed7e-478b-aed0-c7518354d426@github.com>

On Mon, 17 Nov 2025 13:50:30 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Addressed reviewer's comments.

Marked as reviewed by dcubed (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 140:

> 138: // launch resumer       enter threadLock
> 139: // <launch returns>     while !READY_TO_NOTIFY  resumer running
> 140: // :                    threadLock.wait(1)      wait for notify

The wait(1) call is in the while-loop. Please insert two spaces before the `threadlock.wait(1)` call.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 235:

> 233:                 } catch (NumberFormatException nfe) {
> 234:                     System.err.println("'" + args[argIndex] +
> 235:                             "': invalid test_case value.");

The leading double quote should be lined up with the one on the previous line.

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 251:

> 249:                 } catch (NumberFormatException nfe) {
> 250:                     System.err.println("'" + args[argIndex] +
> 251:                             "': invalid time_max value.");

The leading double quote should be lined up with the one on the previous line.

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3474239279
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535265622
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535273619
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535274696

From dcubed at openjdk.org  Mon Nov 17 19:34:28 2025
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 17 Nov 2025 19:34:28 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
 <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>
Message-ID: <JcVqw5qDeiLA8Mcn28-d6yhXTJWuyeOzfT2CmAqllkI=.207a08f8-530a-4b77-8e04-97b0dee3df4b@github.com>

On Mon, 17 Nov 2025 13:45:51 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 552:
>> 
>>> 550:                 // wait for the waiter thread to block
>>> 551:                 logDebug("before contended enter wait");
>>> 552:                 int retCode = wait4ContendedEnter(waiter);
>> 
>> Since we are waiting here for ContendedEnter by the waiter thread, do we really
>> need the above `sleep(200)` or are we just being polite CPU resource wise?
>
> Maybe I do not fully understand the question, but isn't it what differentiates test case 2 from test case 3?

Sorry, I wasn't very clear. I'm questioning the need for the 200ms delay since our call
to `wait4ContendedEnter` will already delay the calling thread. Since @pchilano requested
the addition of the 200ms delay, he should probably chime in here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535285282

From sspitsyn at openjdk.org  Tue Nov 18 00:54:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 18 Nov 2025 00:54:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
Message-ID: <ugq-YIGBghITQDtCCSL5_y2o51xEoaDo21L59Qfg3QY=.290f1b4d-1985-4a05-94ea-02d86cb56be4@github.com>

On Mon, 17 Nov 2025 13:50:30 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Addressed reviewer's comments.

src/hotspot/share/runtime/objectMonitor.cpp line 1950:

> 1948:         // as having "-locked" the monitor, but the OS and java.lang.Thread
> 1949:         // states will still report that the thread is blocked trying to
> 1950:         // acquire it.

Q: I have a concern here. Did we have a similar inconsistency before? As I see, this can be observable not only by thread dumps but also by JVMTI in general (independently of the thread's suspend status). Dan, can you comment on this, please?

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 52:

> 50:  * @compile SuspendWithObjectMonitorWait.java
> 51:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 3
> 52:  */

Q: I'm not that happy with adding this complexity into one single test. Would it make sense to split `doWork1`, `doWork2` and `doWork3` tests into independent test sharing some parts, e.g. .cpp file, `SuspendWithObjectMonitorWaitWorker` class etc.? Then the only duplication will be the `main()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535945583
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2535957986

From dholmes at openjdk.org  Tue Nov 18 02:56:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Nov 2025 02:56:16 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
Message-ID: <CUpzQ08Bz1FCRhEHJzNa1rx6VhEtJjD20Ku6dG26uG8=.621f8c61-5924-4f7e-a1c1-64d0457714a4@github.com>

On Sat, 15 Nov 2025 05:34:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
>> 
>> 
>> try (var err = new PrintWriter(System.err);
>>       var out = new PrintWriter(System.out)) {
>>      out.println("Hello Confused World");
>> }
>> 
>> 
>> This has the side effect of closing the JVM's STDOUT.
>> 
>> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
>> 
>> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
>> 
>> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
>> 
>> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
>> 
>> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.
>
> The fix seems fine for this case.
> 
> VM itself may open a lot of files for different logs (JFR, JIT logs, UL, etc). May VM close some before you open AOT file which could cause the same issue? Is it possible to track life time of such files to make sure we don't write into them after they are closed?

@vnkozlov I think stdout/stderr are special in this regard because the Java code closed a handle that the VM is still actively using. It would be a clear bug in the VM if we closed a file whilst still being used by the VM code.

That said this still seems like a VM bug to me. If Java code closes System.out/err that should not affect stdout/stderr as used by the VM. Maybe the fact this isn't an issue on Posix masked the fact it is a general issue. We should be able to dup the Handle in the VM so that it can't possibly later refer to a different output device.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3544795786

From dholmes at openjdk.org  Tue Nov 18 03:00:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Nov 2025 03:00:17 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64
In-Reply-To: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
Message-ID: <h0A4PYQoUqKt9X6TSCIcZFBPUnr4E1vln_6rsuvspzY=.982c0d22-704d-48a7-88f3-23bdfc7131b3@github.com>

On Mon, 17 Nov 2025 14:31:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> On linux-aarch64, when page size is 64K, the minimal java thread stack size is 448K. So this PR increase the minimal java thread stack size in test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java. Below is the calculation formula for the minimal java thread stack size:
> 
> 
> page_size = 64K
> _java_thread_min_stack_allowed = 72K
> _stack_red_zone_size = align_up(StackRedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_yellow_zone_size = align_up(StackYellowPages * unit, page_size) = align_up(2*4K, 64K) = 64K
> _stack_reserved_zone_size = align_up(StackReservedPages * unit, page_size) = align_up(1*4K, 64K) = 64K
> _stack_shadow_zone_size = align_up(StackShadowPages * unit, page_size) = align_up(25*4K, 64K) = 128K
> _java_thread_min_stack_allowed = align_up(72K+64K+64K+64K+128K, 64K) = 448K
> 
> 
> Change has been verified locally both on linux-x64 and linux-aarch64.

A more resilient change would be to add a WhiteBox API to obtain the minimum stack for the actual platform in use, and then exec the VM with that as an -Xss value. Is that something you can do?

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

PR Comment: https://git.openjdk.org/jdk/pull/28352#issuecomment-3544803277

From syan at openjdk.org  Tue Nov 18 03:14:04 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 18 Nov 2025 03:14:04 GMT
Subject: RFR: 8371948: TestStackOverflowDuringInit.java fails xss too small
 on linux-aarch64
In-Reply-To: <h0A4PYQoUqKt9X6TSCIcZFBPUnr4E1vln_6rsuvspzY=.982c0d22-704d-48a7-88f3-23bdfc7131b3@github.com>
References: <P6KhJ0rZttqTHVxuVi_POYRVmy2oGpaUj03Gnz3LXOQ=.9449af19-abc3-44ad-99e9-6e70ce008e3c@github.com>
 <h0A4PYQoUqKt9X6TSCIcZFBPUnr4E1vln_6rsuvspzY=.982c0d22-704d-48a7-88f3-23bdfc7131b3@github.com>
Message-ID: <2bK1xFujB5uKcpx9X3gK94Scv1HGFb-K9MHQWnLR6m8=.6122ad64-c3ff-48c9-bdf1-61f8a2b61c0d@github.com>

On Tue, 18 Nov 2025 02:57:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> A more resilient change would be to add a WhiteBox API to obtain the minimum stack for the actual platform in use, and then exec the VM with that as an -Xss value. Is that something you can do?

Okey, Thanks for the suggestion, I will try this in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28352#issuecomment-3544832908

From iklam at openjdk.org  Tue Nov 18 03:42:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 03:42:01 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
Message-ID: <3qBnky8giDXZXWtNaNoUJ2QIM7JBtXEbUHGaN0FjXbQ=.f0e1c86e-9f1d-4925-8928-0c0356ee6b09@github.com>

On Sat, 15 Nov 2025 05:34:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
>> 
>> 
>> try (var err = new PrintWriter(System.err);
>>       var out = new PrintWriter(System.out)) {
>>      out.println("Hello Confused World");
>> }
>> 
>> 
>> This has the side effect of closing the JVM's STDOUT.
>> 
>> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
>> 
>> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
>> 
>> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
>> 
>> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
>> 
>> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.
>
> The fix seems fine for this case.
> 
> VM itself may open a lot of files for different logs (JFR, JIT logs, UL, etc). May VM close some before you open AOT file which could cause the same issue? Is it possible to track life time of such files to make sure we don't write into them after they are closed?

@vnkozlov 

Only file descriptors 0, 1, and 2 can be closed by user apps. E.g.,`FileDescriptor.out`:

https://github.com/openjdk/jdk/blob/696821670e11fee003906806f081038032ac4985/src/java.base/share/classes/java/io/FileDescriptor.java#L159

Other files opened by the JVM (JFR, etc) cannot be closed by the app, as there are public no APIs to get their file descriptors.

On Unix, file descriptors 0, 1, and 2 are treated specially in io_util_md.c. We keep those file descriptors valid using `dup2()`, so they can never be recycled to files that are opened in the future:

https://github.com/openjdk/jdk/blob/696821670e11fee003906806f081038032ac4985/src/java.base/unix/native/libjava/io_util_md.c#L161-L168

However, there are no such handling on Windows:

https://github.com/openjdk/jdk/blob/696821670e11fee003906806f081038032ac4985/src/java.base/windows/native/libjava/io_util_md.c#L551-L553

On Windows, each open file is represented by a `HANDLE`, which is a 32- or 64-bit integer. After `System.out.close()` is called from the app, the `HANDLE` that represented STDOUT is closed, so `tty->print()` will stop printing to the stdout. However, sometimes (the integer value of) this `HANDLE` can be reused by Windows when opening a new file, thus causing `tty->print()` to write to the new file, leading to the current issue.

The `dup2()` call on Unix basically prevents the file descriptor to be reused. As far as I know, there are no equivalent APIs on Windows.

@dholmes-ora 

> If Java code closes System.out/err that should not affect stdout/stderr as used by the VM. Maybe the fact this isn't an issue on Posix masked the fact it is a general issue. We should be able to dup the Handle in the VM so that it can't possibly later refer to a different output device.

This would change the behavior of the past 25 years, where `System.out.close()` has meant "this current process should no longer write to the stdout out". This applies to Java code, JVM, and JNI code.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3544883037

From iklam at openjdk.org  Tue Nov 18 03:50:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 03:50:00 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
Message-ID: <2LfWgpluGjb_Ri2oCOmrM8AMsmtTdgAyA7N4XEMZ3Wk=.d15790f7-fa7c-45bc-a940-32ebe4778695@github.com>

On Sat, 15 Nov 2025 04:50:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
> 
> 
> try (var err = new PrintWriter(System.err);
>       var out = new PrintWriter(System.out)) {
>      out.println("Hello Confused World");
> }
> 
> 
> This has the side effect of closing the JVM's STDOUT.
> 
> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
> 
> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
> 
> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
> 
> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
> 
> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.

We could try to intercept the native calls to prevent writes to stdout/stderr when the underlying file descriptors have been closed by the Java program. However, we have very extensive use of C library functions such as `printf`, `fprinf`, `vfprinf`, etc, not just in HotSpot but in various other JDK libraries. So we would need to add an indirection in all those call sites.

Also, there's no way for us to intercept such calls from JNI libraries.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3544898959

From kvn at openjdk.org  Tue Nov 18 05:14:06 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Nov 2025 05:14:06 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
Message-ID: <EhsxsuiPe0P4GK0Iz_szV7Ljj9rdMzA6MzU44maOwDQ=.cf08ed8a-8a39-4dd1-af4a-3ce8f990f63d@github.com>

On Sat, 15 Nov 2025 04:50:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
> 
> 
> try (var err = new PrintWriter(System.err);
>       var out = new PrintWriter(System.out)) {
>      out.println("Hello Confused World");
> }
> 
> 
> This has the side effect of closing the JVM's STDOUT.
> 
> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
> 
> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
> 
> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
> 
> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
> 
> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.

@iklam thank you for explaining the issue in details. You fix is reusable for me based on this.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28335#pullrequestreview-3475480680

From dholmes at openjdk.org  Tue Nov 18 07:07:07 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Nov 2025 07:07:07 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
In-Reply-To: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
Message-ID: <V1HqpZEdGQoPTtRJueqy4cDkS2TQWFlDbGAxggROW6I=.02e6116a-0c40-43f7-938c-fd8ea11786b6@github.com>

On Thu, 6 Nov 2025 08:51:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
> 
> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> 
> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
> 
> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # CreateCoredumpOnCrash turned off, no core file dumped
> 
> **Scenario 2: `get_core_path` errors**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core path is unknown, trying core.1552174 (may not exist)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: core.1552174 (may not exist)
> 
> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/foo/bar/core.1555400)
> 
> **Scenario 4: the resource limit for core dumps could not be determined**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but couldn't deduce rlim, trying /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #  [...]
>> # Core dump will be written. Default location: /tmp/cores/core.%e.1560382.%h.%t (may not exist)
> 
> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # A fatal er...

src/hotspot/os/posix/os_posix.cpp line 132:

> 130:         buf.print("core dumps may be processed with ");
> 131:       }
> 132:       buf.print("%s", core_path);

The only thing I don't like here is this part. I know it looks weird to have "Default location:  Core dumps may be processed with ..." but I think it is less informative to skip pointing out that this case is not actually a location at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2536569162

From dholmes at openjdk.org  Tue Nov 18 07:07:08 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Nov 2025 07:07:08 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
In-Reply-To: <V1HqpZEdGQoPTtRJueqy4cDkS2TQWFlDbGAxggROW6I=.02e6116a-0c40-43f7-938c-fd8ea11786b6@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <V1HqpZEdGQoPTtRJueqy4cDkS2TQWFlDbGAxggROW6I=.02e6116a-0c40-43f7-938c-fd8ea11786b6@github.com>
Message-ID: <PvMwSRBQoo_Si-RCyP3wOAaoQr0jKQu3yGjAOeZI8Ns=.57bcfb0b-0e98-49dc-9fd9-fb68008f67f0@github.com>

On Tue, 18 Nov 2025 07:02:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core path is unknown, trying core.1552174 (may not exist)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.1552174 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/foo/bar/core.1555400)
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but couldn't deduce rlim, trying /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #  [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disabled. To enable core dumping, try "ulimit -c u...
>
> src/hotspot/os/posix/os_posix.cpp line 132:
> 
>> 130:         buf.print("core dumps may be processed with ");
>> 131:       }
>> 132:       buf.print("%s", core_path);
> 
> The only thing I don't like here is this part. I know it looks weird to have "Default location:  Core dumps may be processed with ..." but I think it is less informative to skip pointing out that this case is not actually a location at all.

Or getting rid of the double negative, I think it is beneficial to always point out that this is not actually a location.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2536572730

From mbaesken at openjdk.org  Tue Nov 18 09:23:31 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Nov 2025 09:23:31 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <Vxb5s3-a97MSfXsESNA5FmTP0qKBKZ_jYuRDW183p20=.8c2cf58d-0179-472d-b023-5671ac537bb7@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <Vxb5s3-a97MSfXsESNA5FmTP0qKBKZ_jYuRDW183p20=.8c2cf58d-0179-472d-b023-5671ac537bb7@github.com>
Message-ID: <ZLVoT69m-Ug7z8M9r4Ln6JHuRqzHcHlivn_9Fw46sbw=.ec7dd71e-42ba-4cb1-b758-c50c4e743045@github.com>

On Mon, 17 Nov 2025 01:02:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think this is completely unnecessary - `sysinfo` on Linux can't really fail, the only error possible is EFAULT if you pass a bad pointer for the struct - so don't do that.
> 
> Replacing numbers with words in the logging could break external parsing scripts.

Hi David , not sure how likely those failures are.  Back then in the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522)  we discussed the checking might be needed and that's why the JBS issue was created. 
Checking other projects for potential sysinfo failures it seems that the 'bad pointer' issue you referred to is indeed the most likely one.
But if it is really 'completely unnecessary' we should probably kick out the checks we do at a number of places in the codebase ?
https://github.com/search?q=repo%3Aopenjdk%2Fjdk+%22sysinfo%28%22&type=code

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

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3546401054

From mbaesken at openjdk.org  Tue Nov 18 10:07:06 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 18 Nov 2025 10:07:06 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

If you search github, you find also a number of places where EPERM is checked after sysinfo, not sure if this is really happening these days on our platforms ?

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

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3546620502

From aartemov at openjdk.org  Tue Nov 18 10:14:22 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 10:14:22 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <A20ZLkmDxZHTscHTY9iVwaO1jEX0n_jK4dvFIC1LsPI=.c7a1efb4-ed7e-478b-aed0-c7518354d426@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
 <A20ZLkmDxZHTscHTY9iVwaO1jEX0n_jK4dvFIC1LsPI=.c7a1efb4-ed7e-478b-aed0-c7518354d426@github.com>
Message-ID: <KOYbj_QCIBlnrg300pGhuvSaSEc-7RQzKoc5LH2q7_w=.66159ec7-3f04-4963-baf3-35647fd677d0@github.com>

On Mon, 17 Nov 2025 19:23:52 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Addressed reviewer's comments.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 140:
> 
>> 138: // launch resumer       enter threadLock
>> 139: // <launch returns>     while !READY_TO_NOTIFY  resumer running
>> 140: // :                    threadLock.wait(1)      wait for notify
> 
> The wait(1) call is in the while-loop. Please insert two spaces before the `threadlock.wait(1)` call.

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 235:
> 
>> 233:                 } catch (NumberFormatException nfe) {
>> 234:                     System.err.println("'" + args[argIndex] +
>> 235:                             "': invalid test_case value.");
> 
> The leading double quote should be lined up with the one on the previous line.

Addressed.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 251:
> 
>> 249:                 } catch (NumberFormatException nfe) {
>> 250:                     System.err.println("'" + args[argIndex] +
>> 251:                             "': invalid time_max value.");
> 
> The leading double quote should be lined up with the one on the previous line.

Addressed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2537288143
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2537288285
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2537288511

From aartemov at openjdk.org  Tue Nov 18 10:14:19 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 10:14:19 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v10]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <WwygcxPd-fZ1BtaOiADco08l5JBAF-daSgXyYUahYYQ=.3684be06-e786-4672-96e8-207817da1025@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8366659: Addressed reviewer's comments.
 - 8366659: Addressed reviewer's comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/28725284..a429cb26

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

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

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

From aseoane at openjdk.org  Tue Nov 18 10:15:06 2025
From: aseoane at openjdk.org (Anton Seoane Ampudia)
Date: Tue, 18 Nov 2025 10:15:06 GMT
Subject: RFR: 8213762: Deprecate Xmaxjitcodesize
Message-ID: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>

This PR deprecates the `Xmaxjitcodesize` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behaviour in the future.

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

Commit messages:
 - Add deprecation notice to Xmaxjitcodesize

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

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

From alanb at openjdk.org  Tue Nov 18 11:06:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Nov 2025 11:06:01 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>
Message-ID: <E73tqYoGeh5AWo_rHcHpJA1ZmCAszHjoUdFkbwyy-AY=.d2f77906-753e-43a6-82ee-f29522f0d307@github.com>

On Tue, 18 Nov 2025 10:03:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> If you search github, you find also a number of places where EPERM is checked after sysinfo, not sure if this is really happening these days on our platforms ?

seccomp comes up periodically where random syscalls fail with EPERM as they aren't permitted by the filter. I don't know if this is what you found in your search but the possibility of seccomp or interposer libraries creates the possibility of syscall failing, or failing with errors that aren't documented for the syscall.

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

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3546964776

From jsjolen at openjdk.org  Tue Nov 18 12:24:36 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 18 Nov 2025 12:24:36 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <3qBnky8giDXZXWtNaNoUJ2QIM7JBtXEbUHGaN0FjXbQ=.f0e1c86e-9f1d-4925-8928-0c0356ee6b09@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
 <3qBnky8giDXZXWtNaNoUJ2QIM7JBtXEbUHGaN0FjXbQ=.f0e1c86e-9f1d-4925-8928-0c0356ee6b09@github.com>
Message-ID: <3l9QsqUQgEtZetyMGjHaWU_l6haVR6Nl6FedO6k6nmo=.0708fa57-9b53-47c8-81b7-bfb04c1a717a@github.com>

On Tue, 18 Nov 2025 03:38:26 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>This would change the behavior of the past 25 years, where System.out.close() has meant "this current process should no longer write to the stdout out". This applies to Java code, JVM, and JNI code.

Sorry, I am confused. I thought that this did not apply to Linux, so for 25 years the meaning has differed between Windows and Linux?

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3547371449

From stefank at openjdk.org  Tue Nov 18 12:38:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 18 Nov 2025 12:38:55 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v2]
In-Reply-To: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
Message-ID: <ZmqjDzE70Dmk5LirDY-oC5-kIFeUWVzwhbCauKz1wWs=.38f4db3e-f280-45f1-a8cf-a30dfe9abef5@github.com>

> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
> 
> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
> 
> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
> 
> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
> 
> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
> 
> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
> 
> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
> 
> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
> 
> There are some G1 specific details to look at:
> 
> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
> 
> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
> 
> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert?
> 
> This has been ...

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Review comments
 - Merge remote-tracking branch 'upstream/master' into remove_2s_shutdown_workaround
 - Filter out ConcurrentGCThreads from GC operation shutdown
 - Revert VM_G1PauseConcurrent::doit_prologue
 - Sleep from concurrent thread
 - Move log_cpu_time back to Universe
 - Block for shutdown in GC safepoint prologue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28349/files
  - new: https://git.openjdk.org/jdk/pull/28349/files/c46b90df..b5b7c68a

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

  Stats: 7837 lines in 142 files changed: 6605 ins; 345 del; 887 mod
  Patch: https://git.openjdk.org/jdk/pull/28349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28349/head:pull/28349

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

From stefank at openjdk.org  Tue Nov 18 12:46:28 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 18 Nov 2025 12:46:28 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v3]
In-Reply-To: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
Message-ID: <n24dihMShoF8m1mKVFnuVmofbx6INKjSbbf6ebYg77Y=.9453e9f2-bc31-4ddc-9e1f-733a4da06692@github.com>

> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
> 
> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
> 
> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
> 
> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
> 
> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
> 
> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
> 
> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
> 
> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
> 
> There are some G1 specific details to look at:
> 
> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
> 
> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
> 
> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert?
> 
> This has been ...

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Add comment to block_if_java_thread

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28349/files
  - new: https://git.openjdk.org/jdk/pull/28349/files/b5b7c68a..c5f65378

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

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

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

From stefank at openjdk.org  Tue Nov 18 12:46:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 18 Nov 2025 12:46:30 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v3]
In-Reply-To: <Yp9vslOkFXTa4CZ48nNaOU3EPRCZgk0rftBLKhWBeas=.3531f18c-4ade-4dd6-bc43-499ba83809ae@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com>
 <Yp9vslOkFXTa4CZ48nNaOU3EPRCZgk0rftBLKhWBeas=.3531f18c-4ade-4dd6-bc43-499ba83809ae@github.com>
Message-ID: <F7qDjg4Io48m2zJdwmiZP9pcqMpQAv_8dIf1SAfVcpg=.daf8088a-8abc-45b8-9e4b-8a7d2b4a52e8@github.com>

On Tue, 18 Nov 2025 12:17:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcVMOperations.cpp line 101:
>> 
>>> 99:     while (true) {
>>> 100:       Heap_lock->wait();
>>> 101:     }
>> 
>> The intention here is to block all java-threads indefinitely, and those threads don't need to wait for any signals. I wonder if using a local always-zero semaphore might convey the intention more explicitly.
>
> It also has the side-effect that it releases the Heap_lock and moves the thread into the blocked state. If we don't release the lock then we will not be able to complete the shutdown sequence, which acquires the Heap_lock before the exit VM operation (or shutting down the VM thread).

I've pushed a comment stating the above. Maybe that helps explaining why Heap_lock->wait() is called.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2538043494

From ayang at openjdk.org  Tue Nov 18 13:00:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Nov 2025 13:00:12 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v3]
In-Reply-To: <F7qDjg4Io48m2zJdwmiZP9pcqMpQAv_8dIf1SAfVcpg=.daf8088a-8abc-45b8-9e4b-8a7d2b4a52e8@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com>
 <Yp9vslOkFXTa4CZ48nNaOU3EPRCZgk0rftBLKhWBeas=.3531f18c-4ade-4dd6-bc43-499ba83809ae@github.com>
 <F7qDjg4Io48m2zJdwmiZP9pcqMpQAv_8dIf1SAfVcpg=.daf8088a-8abc-45b8-9e4b-8a7d2b4a52e8@github.com>
Message-ID: <b0cAb-GfQuhI2-mOizl2hkVtrXkOYV4fMGHQu_N1lHg=.a5a6bae8-1f98-49ca-9238-908f489e0d2c@github.com>

On Tue, 18 Nov 2025 12:43:25 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> It also has the side-effect that it releases the Heap_lock and moves the thread into the blocked state. If we don't release the lock then we will not be able to complete the shutdown sequence, which acquires the Heap_lock before the exit VM operation (or shutting down the VM thread).
>
> I've pushed a comment stating the above. Maybe that helps explaining why Heap_lock->wait() is called.

> It also has the side-effect that it releases the Heap_lock ...

Yes. My msg was probably unclear; I meant to suggest using sth like:


Heap_lock->unlock();
{
  Semaphore always_blocked_sema{0};
  always_blocked_sema.wait(); // never return
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2538103942

From aartemov at openjdk.org  Tue Nov 18 13:03:35 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 13:03:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v11]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <5fIR4uxrdE0GVVCOwUYVlz5OyBpiio0fe32-BKOmO_I=.2b262076-a045-4a51-929f-2fb6e5201880@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Refactored the big test into 3 smaller tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/a429cb26..3da08471

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

  Stats: 1696 lines in 7 files changed: 921 ins; 773 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Tue Nov 18 13:03:37 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 13:03:37 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v9]
In-Reply-To: <ugq-YIGBghITQDtCCSL5_y2o51xEoaDo21L59Qfg3QY=.290f1b4d-1985-4a05-94ea-02d86cb56be4@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <lr4CjD0LLPfGGCLOpi1vrr9JTgrkF4nbvCJGvlGK7gM=.1c8bc93d-c4ec-4ff8-a1af-b79018fa3037@github.com>
 <ugq-YIGBghITQDtCCSL5_y2o51xEoaDo21L59Qfg3QY=.290f1b4d-1985-4a05-94ea-02d86cb56be4@github.com>
Message-ID: <ZBouMKx3jvovFMLoB93H-GZ7fAt1Q1dbb-rbEQuMyog=.91d1a23f-f6ec-4bfb-a646-61095840c4a4@github.com>

On Tue, 18 Nov 2025 00:48:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Addressed reviewer's comments.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait.java line 52:
> 
>> 50:  * @compile SuspendWithObjectMonitorWait.java
>> 51:  * @run main/othervm/native -agentlib:SuspendWithObjectMonitorWait SuspendWithObjectMonitorWait 3
>> 52:  */
> 
> Q: I'm not that happy with adding this complexity into one single test. It is usually not easy to deal with such big and multi-mode tests. Would it make sense to split `doWork1`, `doWork2` and `doWork3` tests into independent tests `SuspendWithObjectMonitorWait{1|2|3}.java` sharing some parts, e.g. .cpp file, `SuspendWithObjectMonitorWaitWorker.java` class etc.? Then the only duplication will be the `main()` method.

Actually I agree, it has become way too long. I refactored it into 3 smaller tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2538107049

From azafari at openjdk.org  Tue Nov 18 13:09:12 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 18 Nov 2025 13:09:12 GMT
Subject: RFR: 8371778: Make MallocMemorySummary::_snapshot a DeferredStatic
In-Reply-To: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
References: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
Message-ID: <MkIU6tIe4xXPG43D_nl_sROrvhljCVbJHeEsd8NA4pg=.0180e1e6-2409-495a-9929-ec8bb968b30f@github.com>

On Wed, 12 Nov 2025 07:48:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR wraps the` MallocMemorySummary::_snapshot` in a `DeferredStatic`. This is not strictly necessary as MallocMemorySnapshot does not have a non-trivial constructor, but it does give us more consistency and does act as a safe guard for future changes. 
> 
> Testing: GHA

Thank you for this. Looks good to me.

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

Marked as reviewed by azafari (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28257#pullrequestreview-3477740722

From jsjolen at openjdk.org  Tue Nov 18 13:09:13 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 18 Nov 2025 13:09:13 GMT
Subject: RFR: 8371778: Make MallocMemorySummary::_snapshot a DeferredStatic
In-Reply-To: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
References: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
Message-ID: <p8SoOWhdm3MTNNpTR93-Dj_LADFsT883CyFMKgMEbhw=.55b426a0-428c-4599-aaa8-91066a5b78a1@github.com>

On Wed, 12 Nov 2025 07:48:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR wraps the` MallocMemorySummary::_snapshot` in a `DeferredStatic`. This is not strictly necessary as MallocMemorySnapshot does not have a non-trivial constructor, but it does give us more consistency and does act as a safe guard for future changes. 
> 
> Testing: GHA

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/28257#issuecomment-3547565038

From jsjolen at openjdk.org  Tue Nov 18 13:09:13 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 18 Nov 2025 13:09:13 GMT
Subject: Integrated: 8371778: Make MallocMemorySummary::_snapshot a
 DeferredStatic
In-Reply-To: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
References: <dvNEF8R47_I9p3Vpy2oKVgK80GIVkPM23EiGAMyKrIg=.0232d5ac-6f99-4909-8e3d-7179bd4acea2@github.com>
Message-ID: <dmEuFyJBdxTmCF__HwlRab2FbKUq_MX0jpu7FpfBVPQ=.2d9dc0cb-8097-432b-8eff-c98891231649@github.com>

On Wed, 12 Nov 2025 07:48:38 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR wraps the` MallocMemorySummary::_snapshot` in a `DeferredStatic`. This is not strictly necessary as MallocMemorySnapshot does not have a non-trivial constructor, but it does give us more consistency and does act as a safe guard for future changes. 
> 
> Testing: GHA

This pull request has now been integrated.

Changeset: 36b66e13
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36b66e13c8eca8e460bfd6d900f139408aff9d43
Stats:     5 lines in 2 files changed: 1 ins; 0 del; 4 mod

8371778: Make MallocMemorySummary::_snapshot a DeferredStatic

Reviewed-by: phubner, azafari

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

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

From stuefe at openjdk.org  Tue Nov 18 13:19:08 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 18 Nov 2025 13:19:08 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
In-Reply-To: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
Message-ID: <aYMiAXjLZROiSeYjCQ54VH7S_SBIutHg8abA2FnzWOw=.a9af806e-d170-487f-8297-02d295ce09f1@github.com>

On Thu, 6 Nov 2025 08:51:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
> 
> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> 
> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
> 
> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # CreateCoredumpOnCrash turned off, no core file dumped
> 
> **Scenario 2: `get_core_path` errors**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core path is unknown, trying core.1552174 (may not exist)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: core.1552174 (may not exist)
> 
> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/foo/bar/core.1555400)
> 
> **Scenario 4: the resource limit for core dumps could not be determined**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but couldn't deduce rlim, trying /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #  [...]
>> # Core dump will be written. Default location: /tmp/cores/core.%e.1560382.%h.%t (may not exist)
> 
> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # A fatal er...

Thanks for taking this on. Some suggestions, but looks good overall.

src/hotspot/os/posix/os_posix.cpp line 111:

> 109: // Check core dump limit and report possible place where core can be found
> 110: void os::check_core_dump_prerequisites(char* buffer, size_t bufferSize, bool check_only) {
> 111:   // We can wrap the buffer in a fixed stringStream, this won't free buffer once buf goes out of scope.

The comment is unnecessary; it is clear what happens

src/hotspot/os/posix/os_posix.cpp line 124:

> 122:       // In the warning message, let the user know.
> 123:       if (check_only) {
> 124:         buf.print("core path is unknown, trying ");

The `trying` sounds weird. Who is trying what? It implies that the JVM attempts to try something, possibly suggesting to someone who doesn't know better that it polls the file system for a core file.

Pre-existing, I also wonder about `core.%d` - this is not so common a default that it used to be. AIX does not use it. The linux distributions I know have a different default, systemd-core or Debian's apport... Mac may use it, though `kern.core` allows for many variations. So, not sure. 

I would be fine with a flat "cannot determine core location" and no more. But others may disagree. So not a strong opinion.

src/hotspot/os/posix/os_posix.cpp line 128:

> 126:       buf.print("core.%d (may not exist)", current_process_id());
> 127: #ifdef LINUX
> 128:     } else if (core_path[0] == '"') { // redirect to user process

Pre-existing, but the double quote is odd? Should this not be a pipe symbol? See `man core(5)`.

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

PR Review: https://git.openjdk.org/jdk/pull/28174#pullrequestreview-3477667069
PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2538065187
PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2538104587
PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2538115609

From stuefe at openjdk.org  Tue Nov 18 13:19:10 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 18 Nov 2025 13:19:10 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
In-Reply-To: <PvMwSRBQoo_Si-RCyP3wOAaoQr0jKQu3yGjAOeZI8Ns=.57bcfb0b-0e98-49dc-9fd9-fb68008f67f0@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <V1HqpZEdGQoPTtRJueqy4cDkS2TQWFlDbGAxggROW6I=.02e6116a-0c40-43f7-938c-fd8ea11786b6@github.com>
 <PvMwSRBQoo_Si-RCyP3wOAaoQr0jKQu3yGjAOeZI8Ns=.57bcfb0b-0e98-49dc-9fd9-fb68008f67f0@github.com>
Message-ID: <dn9AhK7n60Dv4ALnLjufMMDWo_7UjewGWFZAlrM5PUQ=.36ad4d16-c0e0-4971-bfd8-69de554655c8@github.com>

On Tue, 18 Nov 2025 07:03:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/os/posix/os_posix.cpp line 132:
>> 
>>> 130:         buf.print("core dumps may be processed with ");
>>> 131:       }
>>> 132:       buf.print("%s", core_path);
>> 
>> The only thing I don't like here is this part. I know it looks weird to have "Default location:  Core dumps may be processed with ..." but I think it is less informative to skip pointing out that this case is not actually a location at all.
>
> Or getting rid of the double negative, I think it is beneficial to always point out that this is not actually a location.

Yes, I agree.

The underlying problem is that `get_core_path()` needs to be redesigned for modern times (since Linux 2.4 that is :-) ) and that what the OS does with a core may not be "write it to the filesystem at this path" but "send it to someone".

A better approach would be just to implement all the "where is the core file?" printout functionality in an OS-dependent function and give up on the idea of POSIX-generic printing. Something like `os::Posix::print_core_file_setup()`, but implemented separately for AIX, BSD, and Linux.

- AIX can suggest a name depending on the AIX-specific `CORE_NAMING` env var. 
- BSD could write a name depending on `sysctl kern.core`. 
- Linux could do some basic parsing of `core_pattern` and either write "is processed with xxx" or "written to xxx" depending on the result. If `core_pattern` is really simple (e.g. no leading pipe symbol and only contains `%P`), it could even guess the file name.

But this would increase the scope of this RFE, and open it to a lot of bikeshedding, and I don't know about backward compatibility (scripts parsing this output) either - so I am absolutely fine with the minor improvements this patch does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2538152660

From phubner at openjdk.org  Tue Nov 18 13:34:03 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 18 Nov 2025 13:34:03 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
In-Reply-To: <aYMiAXjLZROiSeYjCQ54VH7S_SBIutHg8abA2FnzWOw=.a9af806e-d170-487f-8297-02d295ce09f1@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <aYMiAXjLZROiSeYjCQ54VH7S_SBIutHg8abA2FnzWOw=.a9af806e-d170-487f-8297-02d295ce09f1@github.com>
Message-ID: <Jisrc2i0dbHw-x19GyiLEwAJ_k33oU3_-6paM3HNyBs=.bc66e857-d5d7-499b-a6ea-0efe1b89eb34@github.com>

On Tue, 18 Nov 2025 12:59:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core path is unknown, trying core.1552174 (may not exist)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.1552174 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/foo/bar/core.1555400)
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but couldn't deduce rlim, trying /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #  [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.1560382.%h.%t (may not exist)
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disabled. To enable core dumping, try "ulimit -c u...
>
> src/hotspot/os/posix/os_posix.cpp line 128:
> 
>> 126:       buf.print("core.%d (may not exist)", current_process_id());
>> 127: #ifdef LINUX
>> 128:     } else if (core_path[0] == '"') { // redirect to user process
> 
> Pre-existing, but the double quote is odd? Should this not be a pipe symbol? See `man core(5)`.

Strange, right? It's the result of preprocessing done in `os_linux.cpp`'s `os::get_core_path` that checks if `core_pattern[0] == '|'`:

      written = jio_snprintf(buffer, bufferSize,
                             ""%s" (or dumping to %s/core.%d)",
                             &core_pattern[1], p, current_process_id());

You can see these quotes in the output:
> "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (or dumping to /home/opc/betterCoreMsg/core.1555400)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2538245509

From stefank at openjdk.org  Tue Nov 18 13:54:15 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 18 Nov 2025 13:54:15 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v3]
In-Reply-To: <b0cAb-GfQuhI2-mOizl2hkVtrXkOYV4fMGHQu_N1lHg=.a5a6bae8-1f98-49ca-9238-908f489e0d2c@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <_iDFMvioUym2XLXbwgnctxNlmTkq1mil4jX3MuqaEwU=.7c29bae0-15eb-4b1e-a714-33d57eeb39c2@github.com>
 <Yp9vslOkFXTa4CZ48nNaOU3EPRCZgk0rftBLKhWBeas=.3531f18c-4ade-4dd6-bc43-499ba83809ae@github.com>
 <F7qDjg4Io48m2zJdwmiZP9pcqMpQAv_8dIf1SAfVcpg=.daf8088a-8abc-45b8-9e4b-8a7d2b4a52e8@github.com>
 <b0cAb-GfQuhI2-mOizl2hkVtrXkOYV4fMGHQu_N1lHg=.a5a6bae8-1f98-49ca-9238-908f489e0d2c@github.com>
Message-ID: <kwj6xGusFpBKe8BtDRxCIwHXcBUcuApFbiulSlq6kd8=.d70a2ea7-b441-4d4f-8115-78128d033f93@github.com>

On Tue, 18 Nov 2025 12:57:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I've pushed a comment stating the above. Maybe that helps explaining why Heap_lock->wait() is called.
>
>> It also has the side-effect that it releases the Heap_lock ...
> 
> Yes. My msg was probably unclear; I meant to suggest using sth like:
> 
> 
> Heap_lock->unlock();
> {
>   Semaphore always_blocked_sema{0};
>   always_blocked_sema.wait(); // never return
> }

Yeah, I got that. I just don't think that's much clearer. (BTW, you need to use `Semaphore::wait_with_safepoint_check` because `Semaphore::wait` doesn't transition to the blocked state. Or use ThreadBlockInVM.)

Maybe if we had some API that could change the code to be:

Heap_lock->unlock();
block_forever();


But I don't think we have that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2538303025

From aartemov at openjdk.org  Tue Nov 18 14:35:16 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 14:35:16 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Added bool arg to notify_contended_enter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/3da08471..8c82d39c

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

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

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

From aartemov at openjdk.org  Tue Nov 18 14:45:45 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Tue, 18 Nov 2025 14:45:45 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
Message-ID: <aGPfZCwLmf2TONOqGFVUFzDKAVaefS2A8Xwcdun1Qps=.bc9443ab-46a8-4855-97a9-e313d3f32c07@github.com>

On Tue, 18 Nov 2025 14:35:16 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Added bool arg to notify_contended_enter

@sspitsyn the proposed changes do have an effect on the order of jvmti events posted. For instance, in the timed-out case:

Master branch, events posted: wait -> waited -> contended enter -> contended entered
This PR: events posted: wait -> contended enter -> contended entered -> waited

I have checked the specs, and it is not really clear: is (re)entering the OM considered to be a part of `wait` or not?

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3547934122

From jsjolen at openjdk.org  Tue Nov 18 15:21:38 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 18 Nov 2025 15:21:38 GMT
Subject: RFR: 8355225: Test gtest/AsyncLogGtest.java failed at
 droppingMessage_vm: apparent log corruption
Message-ID: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>

Hi,

We've intermittently seen failures from this test. The testing of the actual semantics of dropping async messages is done throughout the entire test file, and then we have a specific test called `droppingMessage`. Certainly, this is a bit unexpected, and perhaps not what we want. What I did find, however, is that this test doesn't follow the same pattern as the other ones that do the drop message testing.

The other tests do:


    test_asynclog_drop_messages();
    AsyncLogWriter::flush(); // <- Insert a flush token to the AsyncLogWriter buffer and await for it to be written
    fflush(nullptr); // <- Force all libc writes to be performed


And the `droppingMessage` test only does `test_asynclog_drop_messages();` .

I'd like us to just insert these two lines and see whether this affects what we see in our testing. This doesn't explain the so-called 'log corruption' when we try to read the content. The best explanation (read: guess) I have for that is that we're concurrently reading and writing to the file, and this leads to data races between the reads and writes.

Thanks.

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

Commit messages:
 - Flush and log

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

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

From iklam at openjdk.org  Tue Nov 18 15:52:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 15:52:44 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <3l9QsqUQgEtZetyMGjHaWU_l6haVR6Nl6FedO6k6nmo=.0708fa57-9b53-47c8-81b7-bfb04c1a717a@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
 <3qBnky8giDXZXWtNaNoUJ2QIM7JBtXEbUHGaN0FjXbQ=.f0e1c86e-9f1d-4925-8928-0c0356ee6b09@github.com>
 <3l9QsqUQgEtZetyMGjHaWU_l6haVR6Nl6FedO6k6nmo=.0708fa57-9b53-47c8-81b7-bfb04c1a717a@github.com>
Message-ID: <EOHIT24pLs9v2qn_Tmh5IyX6DYHBF4UdVIpQa0v4Unw=.4f915ba1-951c-45a5-8bb3-fb1a04dd69f5@github.com>

On Tue, 18 Nov 2025 12:20:40 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> > This would change the behavior of the past 25 years, where System.out.close() has meant "this current process should no longer write to the stdout out". This applies to Java code, JVM, and JNI code.
> 
> Sorry, I am confused. I thought that this did not apply to Linux, so for 25 years the meaning has differed between Windows and Linux?

What you quoted above applies to both Windows and Linux. tty output will no longer appear on stdout (to the console or  any redirected file).

The long standing bug on Windows is that tty output may mysteriously go to *other* files or even sockets. This part doesn't happen on Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3548318520

From kvn at openjdk.org  Tue Nov 18 17:23:32 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Nov 2025 17:23:32 GMT
Subject: RFR: 8213762: Deprecate Xmaxjitcodesize
In-Reply-To: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
References: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
Message-ID: <4QfNZ1lcx8Lawq_iWSm6gAQNUoChkcn3wDhDyl1C7Dk=.d4499f64-ab6e-4e98-8cdf-79ff23163347@github.com>

On Thu, 13 Nov 2025 14:57:30 GMT, Anton Seoane Ampudia <aseoane at openjdk.org> wrote:

> This PR deprecates the `Xmaxjitcodesize` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behaviour in the future.

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28297#pullrequestreview-3478934880

From iklam at openjdk.org  Tue Nov 18 18:13:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 18:13:39 GMT
Subject: RFR: 8371771: CDS test SharedStringsStress.java failed with
 insufficient heap
Message-ID: <jof9Rzx_cLJqs0Rg6oanCjluWuE8by_Y7HkJrI1lTjI=.9b9a888f-ad99-4e02-b33f-31547e20facf@github.com>

Please review this trivial fix. The test requires more initial heap space than the default settings of *some* of our test hosts, so it fails intermittently.

The fix is to specify a large enough `-Xms` (128 MB).

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

Commit messages:
 - 8371771: CDS test SharedStringsStress.java failed with insufficient heap

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

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

From kvn at openjdk.org  Tue Nov 18 19:11:10 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Nov 2025 19:11:10 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v2]
In-Reply-To: <g33oxbvt2FPJNOhucDUVJKjFdNDrawHDDTyV_pSsw5I=.f9ab5a41-2a73-4923-933a-95e9cdaf90d9@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <g33oxbvt2FPJNOhucDUVJKjFdNDrawHDDTyV_pSsw5I=.f9ab5a41-2a73-4923-933a-95e9cdaf90d9@github.com>
Message-ID: <RflnMYaqB2HfVIKXSXhskgoVbLPNIGMdXJT8uHoIn_w=.bcd867ff-9996-4249-aed1-1acfbbf403f8@github.com>

On Fri, 14 Nov 2025 07:04:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview**
>> 
>> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
>> 
>> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
>> 
>> **The fix**
>> 
>> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
>> 
>> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
>> 
>> Please see comments in the above two functions for more details.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - clean up of old C++ class name ArchiveHeapWriter
>  - @ashu-mehra comment -- simplified the criteria for _is_writing_deterministic_heap
>  - Merge branch 'master' into 8363986-heap-region-in-aot-cache-not-determinitic-address
>  - More clean up
>  - fixed aot map
>  - clean up
>  - 8363986: Heap region in CDS archive is not at deterministic address

@iklam you have build failure on ARM 32-bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/28052#issuecomment-3549163706

From kvn at openjdk.org  Tue Nov 18 19:11:13 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Nov 2025 19:11:13 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v2]
In-Reply-To: <WQN17R0u43zvl05RzI0OJJ4GmegzOz66zPoCdNDEBXI=.8e29c573-47f0-46be-b451-64c761dc93e5@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <hAxa0KkLgtQeMNybVP8U-SVF3zMlkvv7ooINvgiHArw=.6b46060d-ac01-4505-b9c9-872385c8209d@github.com>
 <WQN17R0u43zvl05RzI0OJJ4GmegzOz66zPoCdNDEBXI=.8e29c573-47f0-46be-b451-64c761dc93e5@github.com>
Message-ID: <jtJP6t4ue2EgjoxXQ98JLxH5Y5LHy0Rl376xPwQMdbY=.80859f29-85de-4676-a976-a369898ec3b1@github.com>

On Fri, 14 Nov 2025 07:03:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/archiveHeapWriter.cpp line 96:
>> 
>>> 94:     guarantee(MIN_GC_REGION_ALIGNMENT <= G1HeapRegion::min_region_size_in_words() * HeapWordSize, "must be");
>>> 95: 
>>> 96:     if (CDSConfig::old_cds_flags_used() && !CDSConfig::is_dumping_aot_linked_classes() && UseG1GC) {
>> 
>> Wouldn't it be better to add a VM command line flag to indicate that deterministic dump is needed, and use that flag in `Images.gmk`, instead of relying on these conditions?
>
> Since determinism is required only for the old CDS workflow, which will probably be deprecated soon, I think we should avoid adding new VM flags.
> 
> I have updated the code to use  always set `_is_writing_deterministic_heap = true` when using the old CDS workflow. This avoid coupling with the makefiles, and should have minimal impact with the users of old CDS archives. In some cases, runtime relocation might always happen (e.g., G1 with large heaps), but the cost of relocation is usually small (less than 1ms).

Please, no new flags if we can avoid

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28052#discussion_r2539362325

From kvn at openjdk.org  Tue Nov 18 19:28:13 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Nov 2025 19:28:13 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v2]
In-Reply-To: <g33oxbvt2FPJNOhucDUVJKjFdNDrawHDDTyV_pSsw5I=.f9ab5a41-2a73-4923-933a-95e9cdaf90d9@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <g33oxbvt2FPJNOhucDUVJKjFdNDrawHDDTyV_pSsw5I=.f9ab5a41-2a73-4923-933a-95e9cdaf90d9@github.com>
Message-ID: <Rd0vjTsPPF6QFBXuPtx4B3nW_Sx9f7L7Z40EBtFZtxc=.272587fa-7649-4396-815d-cef3d0af3cde@github.com>

On Fri, 14 Nov 2025 07:04:09 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview**
>> 
>> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
>> 
>> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
>> 
>> **The fix**
>> 
>> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
>> 
>> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
>> 
>> Please see comments in the above two functions for more details.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - clean up of old C++ class name ArchiveHeapWriter
>  - @ashu-mehra comment -- simplified the criteria for _is_writing_deterministic_heap
>  - Merge branch 'master' into 8363986-heap-region-in-aot-cache-not-determinitic-address
>  - More clean up
>  - fixed aot map
>  - clean up
>  - 8363986: Heap region in CDS archive is not at deterministic address

src/hotspot/share/cds/aotMappedHeapWriter.cpp line 109:

> 107:       // optimizations such as AOT compiled code require the same compressed oop
> 108:       // encoding to be used in the assembly phase and production run, so we cannot
> 109:       // force (zero-based, no shift) encoding.

In Leyden we do force encoding `(base, shift)` with `-XX:+UseCompatibleCompressedOops` flag in Leyden when AOT code is generated and used:
https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/oops/compressedOops.cpp#L51

The flag is enabled by default when AOT code is used:
https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/cds/cdsConfig.cpp#L121

It allows to use different heap size in production runs.

src/hotspot/share/cds/aotMappedHeapWriter.cpp line 588:

> 586: //     In the production run, if different COOPS encodings are used:
> 587: //         - The heap contents needs to be relocated.
> 588: //         - AOTCodeCache will be disabled.

Not true by default. See my first comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28052#discussion_r2539402767
PR Review Comment: https://git.openjdk.org/jdk/pull/28052#discussion_r2539412737

From kvn at openjdk.org  Tue Nov 18 19:33:12 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 18 Nov 2025 19:33:12 GMT
Subject: RFR: 8371771: CDS test SharedStringsStress.java failed with
 insufficient heap
In-Reply-To: <jof9Rzx_cLJqs0Rg6oanCjluWuE8by_Y7HkJrI1lTjI=.9b9a888f-ad99-4e02-b33f-31547e20facf@github.com>
References: <jof9Rzx_cLJqs0Rg6oanCjluWuE8by_Y7HkJrI1lTjI=.9b9a888f-ad99-4e02-b33f-31547e20facf@github.com>
Message-ID: <mHZr9JPzR2Duq0TlTOs88XMC1VvgQoC5Edv4j891upU=.e81e6dee-2612-41b6-b22d-dc4e25704c4a@github.com>

On Tue, 18 Nov 2025 18:05:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial fix. The test requires more initial heap space than the default settings of *some* of our test hosts, so it fails intermittently.
> 
> The fix is to specify a large enough `-Xms` (128 MB).

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28379#pullrequestreview-3479421988

From dholmes at openjdk.org  Tue Nov 18 20:11:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Nov 2025 20:11:09 GMT
Subject: RFR: 8355225: Test gtest/AsyncLogGtest.java failed at
 droppingMessage_vm: apparent log corruption
In-Reply-To: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
References: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
Message-ID: <9qLspwpPoZ86apO7O0DBzQ_md3z94st8zCiWQJK3r0M=.9771ba98-c396-4bfd-957c-9f8bb2eaa6d9@github.com>

On Tue, 18 Nov 2025 15:12:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> We've intermittently seen failures from this test. The testing of the actual semantics of dropping async messages is done throughout the entire test file, and then we have a specific test called `droppingMessage`. Certainly, this is a bit unexpected, and perhaps not what we want. What I did find, however, is that this test doesn't follow the same pattern as the other ones that do the drop message testing.
> 
> The other tests do:
> 
> 
>     test_asynclog_drop_messages();
>     AsyncLogWriter::flush(); // <- Insert a flush token to the AsyncLogWriter buffer and await for it to be written
>     fflush(nullptr); // <- Force all libc writes to be performed
> 
> 
> And the `droppingMessage` test only does `test_asynclog_drop_messages();` .
> 
> I'd like us to just insert these two lines and see whether this affects what we see in our testing. This doesn't explain the so-called 'log corruption' when we try to read the content. The best explanation (read: guess) I have for that is that we're concurrently reading and writing to the file, and this leads to data races between the reads and writes.
> 
> Thanks.
> 
> Testing: GHA

This does seem to make things more consistent. I'm also not sure it can actually exklain the observed issues though.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28374#pullrequestreview-3479604305

From iklam at openjdk.org  Tue Nov 18 20:15:53 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 20:15:53 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v3]
In-Reply-To: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
Message-ID: <QYmrGTrs9EjqZOCMtqamM-qUR_7Cb45o2zObJjGFMFI=.1f111c06-5d2e-461d-a209-51b1829f8a4b@github.com>

> **Overview**
> 
> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
> 
> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
> 
> **The fix**
> 
> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
> 
> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
> 
> Please see comments in the above two functions for more details.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Updated comments per @vnkozlov review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28052/files
  - new: https://git.openjdk.org/jdk/pull/28052/files/d7dd0730..086c14d1

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

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

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

From iklam at openjdk.org  Tue Nov 18 20:15:59 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 20:15:59 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v2]
In-Reply-To: <Rd0vjTsPPF6QFBXuPtx4B3nW_Sx9f7L7Z40EBtFZtxc=.272587fa-7649-4396-815d-cef3d0af3cde@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <g33oxbvt2FPJNOhucDUVJKjFdNDrawHDDTyV_pSsw5I=.f9ab5a41-2a73-4923-933a-95e9cdaf90d9@github.com>
 <Rd0vjTsPPF6QFBXuPtx4B3nW_Sx9f7L7Z40EBtFZtxc=.272587fa-7649-4396-815d-cef3d0af3cde@github.com>
Message-ID: <kYFbtdH_DHbaLInxQZyEMjbjQ2TTAl3VKs67bWDza_w=.1577c4ae-7bf5-4a6a-840c-b0f59ed516c6@github.com>

On Tue, 18 Nov 2025 19:21:45 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - clean up of old C++ class name ArchiveHeapWriter
>>  - @ashu-mehra comment -- simplified the criteria for _is_writing_deterministic_heap
>>  - Merge branch 'master' into 8363986-heap-region-in-aot-cache-not-determinitic-address
>>  - More clean up
>>  - fixed aot map
>>  - clean up
>>  - 8363986: Heap region in CDS archive is not at deterministic address
>
> src/hotspot/share/cds/aotMappedHeapWriter.cpp line 109:
> 
>> 107:       // optimizations such as AOT compiled code require the same compressed oop
>> 108:       // encoding to be used in the assembly phase and production run, so we cannot
>> 109:       // force (zero-based, no shift) encoding.
> 
> In Leyden we do force encoding `(base, shift)` with `-XX:+UseCompatibleCompressedOops` flag in Leyden when AOT code is generated and used:
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/oops/compressedOops.cpp#L51
> 
> The flag is enabled by default when AOT code is used:
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/cds/cdsConfig.cpp#L121
> 
> It allows to use different heap size in production runs.

I have updated the comments to avoid discussing future AOT optimizations. Instead, it says:


// Determninistic output is not supported by the new AOT workflow, so
// we don't force the (zero-based, no shift) encoding. This way, it is more
// likely that we can avoid oop relocation in the production run.

> src/hotspot/share/cds/aotMappedHeapWriter.cpp line 588:
> 
>> 586: //     In the production run, if different COOPS encodings are used:
>> 587: //         - The heap contents needs to be relocated.
>> 588: //         - AOTCodeCache will be disabled.
> 
> Not true by default. See my first comment.

I have deleted the comment about AOTCodeCache.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28052#discussion_r2539579548
PR Review Comment: https://git.openjdk.org/jdk/pull/28052#discussion_r2539581224

From epeter at openjdk.org  Tue Nov 18 20:19:37 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 18 Nov 2025 20:19:37 GMT
Subject: RFR: 8213762: Deprecate Xmaxjitcodesize
In-Reply-To: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
References: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
Message-ID: <2g9ZwjJFZlz8wfEjQbi87xDgbNFB27WcGCja3XJJB8o=.4a43e98e-f5e4-4d5d-baa9-bf96dabd5cac@github.com>

On Thu, 13 Nov 2025 14:57:30 GMT, Anton Seoane Ampudia <aseoane at openjdk.org> wrote:

> This PR deprecates the `Xmaxjitcodesize` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behaviour in the future.

Looks good to me.

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

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28297#pullrequestreview-3479639066

From pchilanomate at openjdk.org  Tue Nov 18 21:41:43 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 18 Nov 2025 21:41:43 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v8]
In-Reply-To: <JcVqw5qDeiLA8Mcn28-d6yhXTJWuyeOzfT2CmAqllkI=.207a08f8-530a-4b77-8e04-97b0dee3df4b@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <jmOR0maxOPvRGLyYBRAvPUALhiCrCfoVvLs5rotQtz4=.d23f5cc5-c701-4d59-863c-715c9e539c1a@github.com>
 <kaXVZ8CarfvVDEM80C5y20Rqisqrd5FJw8nIRnr4opE=.861a6b90-ddd0-4290-804e-66db305a3393@github.com>
 <S2yv4QYOtfNOvOkxzz27UfnlZLga03jmgSsELfMTicM=.29f377fb-3348-471a-8be7-94e866e9ac72@github.com>
 <JcVqw5qDeiLA8Mcn28-d6yhXTJWuyeOzfT2CmAqllkI=.207a08f8-530a-4b77-8e04-97b0dee3df4b@github.com>
Message-ID: <nLe1FJCTVs3dgEMZ5gg9LOhgwzEYUDZoEP6EN-g5OBY=.e842019d-33a3-41cc-928b-b29354a08b19@github.com>

On Mon, 17 Nov 2025 19:30:44 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Maybe I do not fully understand the question, but isn't it what differentiates test case 2 from test case 3?
>
> Sorry, I wasn't very clear. I'm questioning the need for the 200ms delay since our call
> to `wait4ContendedEnter` will already delay the calling thread. Since @pchilano requested
> the addition of the 200ms delay, he should probably chime in here.

We need it because the `notify()` call already changes the state of the waiter to the BLOCKED state [1] (note that it doesn't unpark it). That means this call to `wait4ContendedEnter` will always return immediately (except for the rare case of the wait timing out before the notify call).

[1] https://github.com/openjdk/jdk/blob/27a38d9093958ae4851bc61b8d3f0d71dc780823/src/hotspot/share/runtime/objectMonitor.cpp#L2077

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2539670920

From iklam at openjdk.org  Tue Nov 18 21:48:47 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 21:48:47 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v4]
In-Reply-To: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
Message-ID: <td7q4iu7tW3UpJKaX6j7ddZO_unizihFdojCIYBJa98=.37dfadca-a7f4-410e-a47b-069bcf409ad3@github.com>

> **Overview**
> 
> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
> 
> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
> 
> **The fix**
> 
> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
> 
> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
> 
> Please see comments in the above two functions for more details.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed arm 32 bit build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28052/files
  - new: https://git.openjdk.org/jdk/pull/28052/files/086c14d1..9871b697

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

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

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

From kbarrett at openjdk.org  Tue Nov 18 21:49:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 18 Nov 2025 21:49:12 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v3]
In-Reply-To: <n24dihMShoF8m1mKVFnuVmofbx6INKjSbbf6ebYg77Y=.9453e9f2-bc31-4ddc-9e1f-733a4da06692@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <n24dihMShoF8m1mKVFnuVmofbx6INKjSbbf6ebYg77Y=.9453e9f2-bc31-4ddc-9e1f-733a4da06692@github.com>
Message-ID: <GpLE4zkWkioycFIuFj2B6YMhJuv1GUldjuvWRH0v6i8=.61c6c039-e91d-4552-a263-9dd57b79437b@github.com>

On Tue, 18 Nov 2025 12:46:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
>> 
>> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
>> 
>> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
>> 
>> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
>> 
>> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
>> 
>> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
>> 
>> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
>> 
>> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
>> 
>> There are some G1 specific details to look at:
>> 
>> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
>> 
>> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
>> 
>> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment to block_if_java_thread

A few remaining comment nits.

Marked as reviewed by kbarrett (Reviewer).

src/hotspot/share/gc/shared/gcVMOperations.cpp line 132:

> 130:   if (_is_shutting_down) {
> 131:     // Block forever if a Java thread is triggering a GC after
> 132:     // the GC have started to shut down.

s/have/has/

src/hotspot/share/gc/shared/gcVMOperations.hpp line 143:

> 141: 
> 142:   // This function returns the value of CollectedHeap::is_shutting_down() that
> 143:   // was recorded in the prologue. Unlike, CollectedHeap::is_shutting_down(),

Remove comma after "Unlike".

src/hotspot/share/gc/shared/gcVMOperations.hpp line 146:

> 144:   // this function can be called without acquiring the Heap_lock.
> 145:   //
> 146:   // This funciton exists so that code that tries to schedule a GC operation

s/funciton/function/

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

PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3479724039
PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3479729718
PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2539666824
PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2539665681
PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2539666064

From iklam at openjdk.org  Tue Nov 18 21:52:01 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 21:52:01 GMT
Subject: RFR: 8371771: CDS test SharedStringsStress.java failed with
 insufficient heap
In-Reply-To: <mHZr9JPzR2Duq0TlTOs88XMC1VvgQoC5Edv4j891upU=.e81e6dee-2612-41b6-b22d-dc4e25704c4a@github.com>
References: <jof9Rzx_cLJqs0Rg6oanCjluWuE8by_Y7HkJrI1lTjI=.9b9a888f-ad99-4e02-b33f-31547e20facf@github.com>
 <mHZr9JPzR2Duq0TlTOs88XMC1VvgQoC5Edv4j891upU=.e81e6dee-2612-41b6-b22d-dc4e25704c4a@github.com>
Message-ID: <E_ycUs7oBCgHiACu5Rrnx7qr9R-_l8djrsdcIsJqCGI=.0ac6afa7-8c4f-40fb-90b6-3197afb2358a@github.com>

On Tue, 18 Nov 2025 19:30:29 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Please review this trivial fix. The test requires more initial heap space than the default settings of *some* of our test hosts, so it fails intermittently.
>> 
>> The fix is to specify a large enough `-Xms` (128 MB).
>
> Good.

Thanks @vnkozlov for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28379#issuecomment-3549569001

From iklam at openjdk.org  Tue Nov 18 21:54:39 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 18 Nov 2025 21:54:39 GMT
Subject: Integrated: 8371771: CDS test SharedStringsStress.java failed with
 insufficient heap
In-Reply-To: <jof9Rzx_cLJqs0Rg6oanCjluWuE8by_Y7HkJrI1lTjI=.9b9a888f-ad99-4e02-b33f-31547e20facf@github.com>
References: <jof9Rzx_cLJqs0Rg6oanCjluWuE8by_Y7HkJrI1lTjI=.9b9a888f-ad99-4e02-b33f-31547e20facf@github.com>
Message-ID: <aF6WJzIZv2JY7YwSbUVMfj-OxPsxySINh4ZOd1QKPTg=.4d7191b3-9fd2-4d12-b680-cfbef2dc2be0@github.com>

On Tue, 18 Nov 2025 18:05:56 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Please review this trivial fix. The test requires more initial heap space than the default settings of *some* of our test hosts, so it fails intermittently.
> 
> The fix is to specify a large enough `-Xms` (128 MB).

This pull request has now been integrated.

Changeset: b086e34f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b086e34f7170631d7568dc50a7c075dc9c2f173b
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8371771: CDS test SharedStringsStress.java failed with insufficient heap

Reviewed-by: kvn

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

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

From kvn at openjdk.org  Wed Nov 19 01:29:11 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 19 Nov 2025 01:29:11 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v4]
In-Reply-To: <td7q4iu7tW3UpJKaX6j7ddZO_unizihFdojCIYBJa98=.37dfadca-a7f4-410e-a47b-069bcf409ad3@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <td7q4iu7tW3UpJKaX6j7ddZO_unizihFdojCIYBJa98=.37dfadca-a7f4-410e-a47b-069bcf409ad3@github.com>
Message-ID: <S2zjaKmumb5a-0TcQdFALgl4GK-uPhjIGs00eqx10TM=.c32f110f-cebe-40ea-9005-1f5f7b97da45@github.com>

On Tue, 18 Nov 2025 21:48:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview**
>> 
>> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
>> 
>> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
>> 
>> **The fix**
>> 
>> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
>> 
>> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
>> 
>> Please see comments in the above two functions for more details.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed arm 32 bit build

Good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28052#pullrequestreview-3480326110

From syan at openjdk.org  Wed Nov 19 01:57:17 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Nov 2025 01:57:17 GMT
Subject: RFR: 8355225: Test gtest/AsyncLogGtest.java failed at
 droppingMessage_vm: apparent log corruption
In-Reply-To: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
References: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
Message-ID: <INagktYvGPLwk2n7mDycgP7xr7sXhZSmuAuGgFK9UHU=.cac7b2b2-c567-461e-8f86-6ca9f0e5c027@github.com>

On Tue, 18 Nov 2025 15:12:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> We've intermittently seen failures from this test. The testing of the actual semantics of dropping async messages is done throughout the entire test file, and then we have a specific test called `droppingMessage`. Certainly, this is a bit unexpected, and perhaps not what we want. What I did find, however, is that this test doesn't follow the same pattern as the other ones that do the drop message testing.
> 
> The other tests do:
> 
> 
>     test_asynclog_drop_messages();
>     AsyncLogWriter::flush(); // <- Insert a flush token to the AsyncLogWriter buffer and await for it to be written
>     fflush(nullptr); // <- Force all libc writes to be performed
> 
> 
> And the `droppingMessage` test only does `test_asynclog_drop_messages();` .
> 
> I'd like us to just insert these two lines and see whether this affects what we see in our testing. This doesn't explain the so-called 'log corruption' when we try to read the content. The best explanation (read: guess) I have for that is that we're concurrently reading and writing to the file, and this leads to data races between the reads and writes.
> 
> Thanks.
> 
> Testing: GHA

Hi, I apply the proposed patch and rebuild the test-image, the test still intermittent fails.

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

PR Comment: https://git.openjdk.org/jdk/pull/28374#issuecomment-3550283435

From asmehra at openjdk.org  Wed Nov 19 02:47:59 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 19 Nov 2025 02:47:59 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v4]
In-Reply-To: <td7q4iu7tW3UpJKaX6j7ddZO_unizihFdojCIYBJa98=.37dfadca-a7f4-410e-a47b-069bcf409ad3@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <td7q4iu7tW3UpJKaX6j7ddZO_unizihFdojCIYBJa98=.37dfadca-a7f4-410e-a47b-069bcf409ad3@github.com>
Message-ID: <MWa6wSNDenbiD7y6O1vOvnTb37mvOiACU3_7Z5xa8cw=.20d889fd-e60c-4852-b48b-dea873816f82@github.com>

On Tue, 18 Nov 2025 21:48:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> **Overview**
>> 
>> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
>> 
>> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
>> 
>> **The fix**
>> 
>> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
>> 
>> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
>> 
>> Please see comments in the above two functions for more details.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed arm 32 bit build

Marked as reviewed by asmehra (Committer).

lgtm

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

PR Review: https://git.openjdk.org/jdk/pull/28052#pullrequestreview-3480508047
PR Comment: https://git.openjdk.org/jdk/pull/28052#issuecomment-3550416184

From syan at openjdk.org  Wed Nov 19 03:29:51 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Nov 2025 03:29:51 GMT
Subject: RFR: 8372125: containers/docker/TestPids.java fails after 8365606
Message-ID: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>

Hi all,

The test containers/docker/TestPids.java seems to be fails after [JDK-8365606](https://bugs.openjdk.org/browse/JDK-8365606)
I think max/-1/ulimited are all acceptable as unlimited pids value.
The change has been verified locally on linux-x64 and linux-aarch64.

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

Commit messages:
 - 8372125: containers/docker/TestPids.java fails after 8365606

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

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

From sspitsyn at openjdk.org  Wed Nov 19 04:57:38 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 04:57:38 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
Message-ID: <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>

On Tue, 18 Nov 2025 14:35:16 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Added bool arg to notify_contended_enter

Thank you for refactoring the test into several tests which share a common part. It is nice!
May I ask you about more refactoring? I'll inline my comments with the refactoring suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3550803652

From iklam at openjdk.org  Wed Nov 19 05:06:24 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Nov 2025 05:06:24 GMT
Subject: RFR: 8363986: Heap region in CDS archive is not at deterministic
 address [v2]
In-Reply-To: <RflnMYaqB2HfVIKXSXhskgoVbLPNIGMdXJT8uHoIn_w=.bcd867ff-9996-4249-aed1-1acfbbf403f8@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
 <g33oxbvt2FPJNOhucDUVJKjFdNDrawHDDTyV_pSsw5I=.f9ab5a41-2a73-4923-933a-95e9cdaf90d9@github.com>
 <RflnMYaqB2HfVIKXSXhskgoVbLPNIGMdXJT8uHoIn_w=.bcd867ff-9996-4249-aed1-1acfbbf403f8@github.com>
Message-ID: <moQ2Sd0usMOxsF53zIYYa3HFN9lLsZwipejrJTKNzTk=.019f0f91-4cd9-45c5-bae3-27f3b9f3c16c@github.com>

On Tue, 18 Nov 2025 19:07:51 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - clean up of old C++ class name ArchiveHeapWriter
>>  - @ashu-mehra comment -- simplified the criteria for _is_writing_deterministic_heap
>>  - Merge branch 'master' into 8363986-heap-region-in-aot-cache-not-determinitic-address
>>  - More clean up
>>  - fixed aot map
>>  - clean up
>>  - 8363986: Heap region in CDS archive is not at deterministic address
>
> @iklam you have build failure on ARM 32-bit.

Thanks @vnkozlov and @ashu-mehra for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28052#issuecomment-3550817879

From sspitsyn at openjdk.org  Wed Nov 19 05:08:33 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 05:08:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
Message-ID: <fDuBWVKs7Dn3InszOukk8szwq73jXBBZpMcSQf1-5vI=.f21965da-161b-4522-8f44-bd5e2de0c8bd@github.com>

On Tue, 18 Nov 2025 14:35:16 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Added bool arg to notify_contended_enter

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 218:

> 216: 
> 217:         return 0;
> 218:     }

Nit: Launch of `Waiter` and `Resumer`, some testing steps and test shutdown are identical for all 3 tests. So, they can be factored out into separate functions located in the base file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2540553311

From iklam at openjdk.org  Wed Nov 19 05:08:36 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Nov 2025 05:08:36 GMT
Subject: Integrated: 8363986: Heap region in CDS archive is not at
 deterministic address
In-Reply-To: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
References: <WXLRQexRrYYH_MhvhNx3TVyaJ_kBI0AXxeyP11hypfs=.a54b770c-7583-40a9-92a0-b2810fa8a860@github.com>
Message-ID: <iQUea5aCgCnlp-ZEdCTnkjCYhHPbK6W6Rr3FIpFNewg=.38edae26-beed-4b2b-9b55-c441bc979027@github.com>

On Thu, 30 Oct 2025 05:46:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> **Overview**
> 
> This PR fixes the problem where the JDK build is not reproducible because the `lib/server/classes*.jsa` files do not always put the heap objects at the same addresses. This bug affects only `+UseCompressedOops`.
> 
> This bug is in generic code and is not specific to any platform. We hadn't hit this bug because our build platforms always allocated the heap at the same location. However, this is no longer true with macOS 26, which puts the heap at random locations.
> 
> **The fix**
> 
> (1) In `ArchiveHeapWriter::init()`, we check if we need deterministic heap contents.
> 
> (2) In `ArchiveHeapWriter::set_requested_address_range()`, if deterministic heap contents are needed, we always put the archived heap objects to just below `0x100000000`, so that we always write the archived oops into the CDS archive with  zero-based, zero-shift encoding.
> 
> Please see comments in the above two functions for more details.

This pull request has now been integrated.

Changeset: 02ff38f2
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/02ff38f2d7f6abc0e4661e8226bc6780b7a11c3a
Stats:     142 lines in 7 files changed: 101 ins; 17 del; 24 mod

8363986: Heap region in CDS archive is not at deterministic address

Reviewed-by: kvn, asmehra

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

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

From dholmes at openjdk.org  Wed Nov 19 05:34:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 05:34:14 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <EOHIT24pLs9v2qn_Tmh5IyX6DYHBF4UdVIpQa0v4Unw=.4f915ba1-951c-45a5-8bb3-fb1a04dd69f5@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
 <3qBnky8giDXZXWtNaNoUJ2QIM7JBtXEbUHGaN0FjXbQ=.f0e1c86e-9f1d-4925-8928-0c0356ee6b09@github.com>
 <3l9QsqUQgEtZetyMGjHaWU_l6haVR6Nl6FedO6k6nmo=.0708fa57-9b53-47c8-81b7-bfb04c1a717a@github.com>
 <EOHIT24pLs9v2qn_Tmh5IyX6DYHBF4UdVIpQa0v4Unw=.4f915ba1-951c-45a5-8bb3-fb1a04dd69f5@github.com>
Message-ID: <_0SVo1RDdcgs94gRaSNBRmI8qiI9a99SthkSSvCtoKQ=.5e032c5d-0790-4952-8dd1-83e9eacf0546@github.com>

On Tue, 18 Nov 2025 15:50:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This would change the behavior of the past 25 years, where System.out.close() has meant "this current process should no longer write to the stdout out". This applies to Java code, JVM, and JNI code.

Perhaps but that seems better than allowing the JVM to write to a file owned by the application just because it happened to close System.out. This could certainly explain some weird file corruption bugs we have seen over the years. And with enough randomness, combined with not normally closing System.out/err that we have not recognized it for the problem that it is.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3550881914

From iklam at openjdk.org  Wed Nov 19 06:52:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Nov 2025 06:52:23 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <_0SVo1RDdcgs94gRaSNBRmI8qiI9a99SthkSSvCtoKQ=.5e032c5d-0790-4952-8dd1-83e9eacf0546@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
 <3qBnky8giDXZXWtNaNoUJ2QIM7JBtXEbUHGaN0FjXbQ=.f0e1c86e-9f1d-4925-8928-0c0356ee6b09@github.com>
 <3l9QsqUQgEtZetyMGjHaWU_l6haVR6Nl6FedO6k6nmo=.0708fa57-9b53-47c8-81b7-bfb04c1a717a@github.com>
 <EOHIT24pLs9v2qn_Tmh5IyX6DYHBF4UdVIpQa0v4Unw=.4f915ba1-951c-45a5-8bb3-fb1a04dd69f5@github.com>
 <_0SVo1RDdcgs94gRaSNBRmI8qiI9a99SthkSSvCtoKQ=.5e032c5d-0790-4952-8dd1-83e9eacf0546@github.com>
Message-ID: <QhOJeAWYUrTbk9uY_N1C7XzDFXVbhKBf8LhoFMiKHwI=.ff2784e4-8892-461e-8486-755fa28b26eb@github.com>

On Wed, 19 Nov 2025 05:31:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > This would change the behavior of the past 25 years, where System.out.close() has meant "this current process should no longer write to the stdout out". This applies to Java code, JVM, and JNI code.
> 
> Perhaps but that seems better than allowing the JVM to write to a file owned by the application just because it happened to close System.out. This could certainly explain some weird file corruption bugs we have seen over the years. And with enough randomness, combined with not normally closing System.out/err that we have not recognized it for the problem that it is.

Maybe. This type of corruption happens only on Windows, so I am not sure if there's enough motivation to make such a change.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3551056851

From jsjolen at openjdk.org  Wed Nov 19 07:18:33 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 19 Nov 2025 07:18:33 GMT
Subject: RFR: 8355225: Test gtest/AsyncLogGtest.java failed at
 droppingMessage_vm: apparent log corruption
In-Reply-To: <INagktYvGPLwk2n7mDycgP7xr7sXhZSmuAuGgFK9UHU=.cac7b2b2-c567-461e-8f86-6ca9f0e5c027@github.com>
References: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
 <INagktYvGPLwk2n7mDycgP7xr7sXhZSmuAuGgFK9UHU=.cac7b2b2-c567-461e-8f86-6ca9f0e5c027@github.com>
Message-ID: <O84y90CGmtNlGY_YmhokzWIuwbxjNrKYUw-mkebKNJg=.e1a90115-991f-457e-8362-86206ee284d5@github.com>

On Wed, 19 Nov 2025 01:52:46 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi, I apply the proposed patch and rebuild the test-image, the test still intermittent fails.

And this is the issue where the logs do show up, but there is no log corruption? It makes sense that that persists, as this code change is meant to ensure that the logs have hit disk before checking for the "missing logs" message. I'm writing to you in the JBS issue for that ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/28374#issuecomment-3551146376

From stefank at openjdk.org  Wed Nov 19 07:21:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 19 Nov 2025 07:21:51 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v4]
In-Reply-To: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
Message-ID: <shP2-MDXK_C_uOidBkPOXGOhul0ZMoWeFNj-smLcuPo=.a6e8de5a-4cf7-4360-98d2-2eb82d23592e@github.com>

> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
> 
> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
> 
> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
> 
> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
> 
> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
> 
> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
> 
> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
> 
> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
> 
> There are some G1 specific details to look at:
> 
> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
> 
> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
> 
> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert?
> 
> This has been ...

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28349/files
  - new: https://git.openjdk.org/jdk/pull/28349/files/c5f65378..8a928cae

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

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28349.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28349/head:pull/28349

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

From stefank at openjdk.org  Wed Nov 19 07:21:58 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 19 Nov 2025 07:21:58 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v3]
In-Reply-To: <GpLE4zkWkioycFIuFj2B6YMhJuv1GUldjuvWRH0v6i8=.61c6c039-e91d-4552-a263-9dd57b79437b@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <n24dihMShoF8m1mKVFnuVmofbx6INKjSbbf6ebYg77Y=.9453e9f2-bc31-4ddc-9e1f-733a4da06692@github.com>
 <GpLE4zkWkioycFIuFj2B6YMhJuv1GUldjuvWRH0v6i8=.61c6c039-e91d-4552-a263-9dd57b79437b@github.com>
Message-ID: <bIAOn1ffZZdlRuP4ksrGHLJyDgOaAs63yqBWSDfDE1w=.7c2ae32e-795e-4f6f-ba41-bd2a1af99946@github.com>

On Tue, 18 Nov 2025 20:48:42 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment to block_if_java_thread
>
> src/hotspot/share/gc/shared/gcVMOperations.cpp line 132:
> 
>> 130:   if (_is_shutting_down) {
>> 131:     // Block forever if a Java thread is triggering a GC after
>> 132:     // the GC have started to shut down.
> 
> s/have/has/

Fixed. Thanks.

> src/hotspot/share/gc/shared/gcVMOperations.hpp line 143:
> 
>> 141: 
>> 142:   // This function returns the value of CollectedHeap::is_shutting_down() that
>> 143:   // was recorded in the prologue. Unlike, CollectedHeap::is_shutting_down(),
> 
> Remove comma after "Unlike".

Fixed. Thanks.

> src/hotspot/share/gc/shared/gcVMOperations.hpp line 146:
> 
>> 144:   // this function can be called without acquiring the Heap_lock.
>> 145:   //
>> 146:   // This funciton exists so that code that tries to schedule a GC operation
> 
> s/funciton/function/

Fixed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2540827549
PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2540827393
PR Review Comment: https://git.openjdk.org/jdk/pull/28349#discussion_r2540827732

From kbarrett at openjdk.org  Wed Nov 19 07:30:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 19 Nov 2025 07:30:56 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v4]
In-Reply-To: <shP2-MDXK_C_uOidBkPOXGOhul0ZMoWeFNj-smLcuPo=.a6e8de5a-4cf7-4360-98d2-2eb82d23592e@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <shP2-MDXK_C_uOidBkPOXGOhul0ZMoWeFNj-smLcuPo=.a6e8de5a-4cf7-4360-98d2-2eb82d23592e@github.com>
Message-ID: <XHjyp6u0jrQuc6pQuJEpNqIkGUua0SaOZQDV0TGgdXw=.449cd2f0-35ca-4995-9dc4-dc053749447d@github.com>

On Wed, 19 Nov 2025 07:21:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
>> 
>> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
>> 
>> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
>> 
>> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
>> 
>> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
>> 
>> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
>> 
>> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
>> 
>> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
>> 
>> There are some G1 specific details to look at:
>> 
>> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
>> 
>> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
>> 
>> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3481203855

From syan at openjdk.org  Wed Nov 19 07:38:36 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 19 Nov 2025 07:38:36 GMT
Subject: RFR: 8355225: Test gtest/AsyncLogGtest.java failed at
 droppingMessage_vm: apparent log corruption
In-Reply-To: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
References: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
Message-ID: <MeccKEdl9fIhh0mV0_fg8jcci6c1jySBKrrA0mZ02dU=.1f004711-35de-4e23-ae4d-806233483ccc@github.com>

On Tue, 18 Nov 2025 15:12:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> We've intermittently seen failures from this test. The testing of the actual semantics of dropping async messages is done throughout the entire test file, and then we have a specific test called `droppingMessage`. Certainly, this is a bit unexpected, and perhaps not what we want. What I did find, however, is that this test doesn't follow the same pattern as the other ones that do the drop message testing.
> 
> The other tests do:
> 
> 
>     test_asynclog_drop_messages();
>     AsyncLogWriter::flush(); // <- Insert a flush token to the AsyncLogWriter buffer and await for it to be written
>     fflush(nullptr); // <- Force all libc writes to be performed
> 
> 
> And the `droppingMessage` test only does `test_asynclog_drop_messages();` .
> 
> I'd like us to just insert these two lines and see whether this affects what we see in our testing. This doesn't explain the so-called 'log corruption' when we try to read the content. The best explanation (read: guess) I have for that is that we're concurrently reading and writing to the file, and this leads to data races between the reads and writes.
> 
> Thanks.
> 
> Testing: GHA

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/28374#pullrequestreview-3481233972

From dholmes at openjdk.org  Wed Nov 19 08:00:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 08:00:46 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <E73tqYoGeh5AWo_rHcHpJA1ZmCAszHjoUdFkbwyy-AY=.d2f77906-753e-43a6-82ee-f29522f0d307@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <4pxXV1nliz8KLnOocflpYiyrxZqADXp8ie9cXrvOfgg=.5f27e765-d8bf-4527-ba69-183fc522ef87@github.com>
 <E73tqYoGeh5AWo_rHcHpJA1ZmCAszHjoUdFkbwyy-AY=.d2f77906-753e-43a6-82ee-f29522f0d307@github.com>
Message-ID: <yS2-J8Qow_bjlLIVO4lqxn4G5NemzOa_984A9PPbpts=.00b5e805-0bc3-4ec7-a6ac-ee91cd10b05f@github.com>

On Tue, 18 Nov 2025 11:01:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> the possibility of seccomp or interposer libraries creates the possibility of syscall failing, or failing with errors that aren't documented for the syscall.

That certainly complicates things and could potentially invalidate any code where we check for the expected/specified set of errors. I grudgingly withdraw my objection.

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

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3551288993

From dholmes at openjdk.org  Wed Nov 19 08:00:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 08:00:46 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
Message-ID: <6wi89g5vMiAiGZzgljM43lQwsgOA5dc94LNBd64AktI=.5e954a04-6e28-4453-8bdd-4c7341a9fb69@github.com>

On Fri, 14 Nov 2025 11:07:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   0 - terminate not needed

src/hotspot/os/linux/os_linux.cpp line 2455:

> 2453:     os::print_dhm(st, "OS uptime:", (long) sinfo.uptime);
> 2454:   } else {
> 2455:     st->print_cr("OS uptime could not be retrieved.");

I think an assert would be preferable here. This code can't be parsed so I think it better not to inject it.

src/hotspot/os/linux/os_linux.cpp line 2594:

> 2592:   } else {
> 2593:     st->print(", swap could not be determined");
> 2594:   }

Again probably better to assert and say nothing, or use 0 as a placeholder.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2540928254
PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2540930104

From jkratochvil at openjdk.org  Wed Nov 19 08:08:25 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 19 Nov 2025 08:08:25 GMT
Subject: RFR: 8372135: clang compilation error
Message-ID: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>

clang-20.1.8-4.fc42.x86_64

src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:212:10: error: 'is_containerized' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
  212 |     bool is_containerized();
      |          ^       
src/hotspot/os/linux/cgroupSubsystem_linux.hpp:284:18: note: overridden virtual function is here
  284 |     virtual bool is_containerized() = 0;
      |                  ^
In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:214:18: error: 'container_type' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
  214 |     const char * container_type() {
      |                  ^
src/hotspot/os/linux/cgroupSubsystem_linux.hpp:288:26: note: overridden virtual function is here
  288 |     virtual const char * container_type() = 0;
      |                          ^
In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:217:54: error: 'memory_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
  217 |     CachingCgroupController<CgroupMemoryController>* memory_controller() { return _memory; }
      |                                                      ^
src/hotspot/os/linux/cgroupSubsystem_linux.hpp:289:62: note: overridden virtual function is here
  289 |     virtual CachingCgroupController<CgroupMemoryController>* memory_controller() = 0;
      |                                                              ^
In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:218:51: error: 'cpu_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
  218 |     CachingCgroupController<CgroupCpuController>* cpu_controller() { return _cpu; }
      |                                                   ^
src/hotspot/os/linux/cgroupSubsystem_linux.hpp:290:59: note: overridden virtual function is here
  290 |     virtual CachingCgroupController<CgroupCpuController>* cpu_controller() = 0;
      |                                                           ^
In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:219:30: error: 'cpuacct_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override  219 |     CgroupCpuacctController* cpuacct_controller() { return _cpuacct; }
      |                              ^
src/hotspot/os/linux/cgroupSubsystem_linux.hpp:291:38: note: overridden virtual function is here
  291 |     virtual CgroupCpuacctController* cpuacct_controller() = 0;
      |                                      ^
5 errors generated.                          
gmake[3]: *** [lib/CompileJvm.gmk:180: build/fastdebug-default-clang/hotspot/variant-server/libjvm/objs/cgroupSubsystem_linux.o] Error 1

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

Commit messages:
 - 8372135: clang compilation error

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

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

From stefank at openjdk.org  Wed Nov 19 08:28:22 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 19 Nov 2025 08:28:22 GMT
Subject: RFR: 8372135: clang compilation error
In-Reply-To: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
References: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
Message-ID: <lVjuWJJ1pZ-VkvjIHqjnX-8NfiQUEbMjJUKxfcYJiQc=.905cd45e-769a-4ec2-9c65-dcf3b93f8d15@github.com>

On Wed, 19 Nov 2025 07:59:32 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> clang-20.1.8-4.fc42.x86_64
> 
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:212:10: error: 'is_containerized' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   212 |     bool is_containerized();
>       |          ^       
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:284:18: note: overridden virtual function is here
>   284 |     virtual bool is_containerized() = 0;
>       |                  ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:214:18: error: 'container_type' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   214 |     const char * container_type() {
>       |                  ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:288:26: note: overridden virtual function is here
>   288 |     virtual const char * container_type() = 0;
>       |                          ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:217:54: error: 'memory_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   217 |     CachingCgroupController<CgroupMemoryController>* memory_controller() { return _memory; }
>       |                                                      ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:289:62: note: overridden virtual function is here
>   289 |     virtual CachingCgroupController<CgroupMemoryController>* memory_controller() = 0;
>       |                                                              ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:218:51: error: 'cpu_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   218 |     CachingCgroupController<CgroupCpuController>* cpu_controller() { return _cpu; }
>       |                                                   ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:290:59: note: overridden virtual function is here
>   290 |     virtual CachingCgroupController<CgroupCpuController>* cpu_controller() = 0;
>       |                                                           ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:219:30: error: 'cpuacct_controller' overrides a member function but is not marked...

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28384#pullrequestreview-3481411217

From duke at openjdk.org  Wed Nov 19 08:40:32 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Nov 2025 08:40:32 GMT
Subject: RFR: 8372135: clang compilation error
In-Reply-To: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
References: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
Message-ID: <Y5vpdnhjlw50hVfJB7itvCPPtNKqRc6FaD8tyyBeXVA=.41b93e86-c653-43d4-b74f-0725e3a1b201@github.com>

On Wed, 19 Nov 2025 07:59:32 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> clang-20.1.8-4.fc42.x86_64
> 
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:212:10: error: 'is_containerized' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   212 |     bool is_containerized();
>       |          ^       
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:284:18: note: overridden virtual function is here
>   284 |     virtual bool is_containerized() = 0;
>       |                  ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:214:18: error: 'container_type' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   214 |     const char * container_type() {
>       |                  ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:288:26: note: overridden virtual function is here
>   288 |     virtual const char * container_type() = 0;
>       |                          ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:217:54: error: 'memory_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   217 |     CachingCgroupController<CgroupMemoryController>* memory_controller() { return _memory; }
>       |                                                      ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:289:62: note: overridden virtual function is here
>   289 |     virtual CachingCgroupController<CgroupMemoryController>* memory_controller() = 0;
>       |                                                              ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:218:51: error: 'cpu_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   218 |     CachingCgroupController<CgroupCpuController>* cpu_controller() { return _cpu; }
>       |                                                   ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:290:59: note: overridden virtual function is here
>   290 |     virtual CachingCgroupController<CgroupCpuController>* cpu_controller() = 0;
>       |                                                           ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:219:30: error: 'cpuacct_controller' overrides a member function but is not marked...

@jankratochvil 
Your change (at version 639fa86234a33468786ab6b9b8fc8cd7b531b0b2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28384#issuecomment-3551433730

From jsjolen at openjdk.org  Wed Nov 19 09:12:12 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 19 Nov 2025 09:12:12 GMT
Subject: RFR: 8372135: clang compilation error
In-Reply-To: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
References: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
Message-ID: <YguWkMOhsTo5KHK7BlV-z1-siGr1D6v11_0tLJAGpTQ=.83842d05-4f4e-4cc4-a9b7-dd81144215f3@github.com>

On Wed, 19 Nov 2025 07:59:32 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> clang-20.1.8-4.fc42.x86_64
> 
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:212:10: error: 'is_containerized' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   212 |     bool is_containerized();
>       |          ^       
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:284:18: note: overridden virtual function is here
>   284 |     virtual bool is_containerized() = 0;
>       |                  ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:214:18: error: 'container_type' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   214 |     const char * container_type() {
>       |                  ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:288:26: note: overridden virtual function is here
>   288 |     virtual const char * container_type() = 0;
>       |                          ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:217:54: error: 'memory_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   217 |     CachingCgroupController<CgroupMemoryController>* memory_controller() { return _memory; }
>       |                                                      ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:289:62: note: overridden virtual function is here
>   289 |     virtual CachingCgroupController<CgroupMemoryController>* memory_controller() = 0;
>       |                                                              ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:218:51: error: 'cpu_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   218 |     CachingCgroupController<CgroupCpuController>* cpu_controller() { return _cpu; }
>       |                                                   ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:290:59: note: overridden virtual function is here
>   290 |     virtual CachingCgroupController<CgroupCpuController>* cpu_controller() = 0;
>       |                                                           ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:219:30: error: 'cpuacct_controller' overrides a member function but is not marked...

Marked as reviewed by jsjolen (Reviewer).

Please wait 24 hours before integrating. This is so that all contributors get a chance to see your PR.

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

PR Review: https://git.openjdk.org/jdk/pull/28384#pullrequestreview-3481599536
PR Comment: https://git.openjdk.org/jdk/pull/28384#issuecomment-3551605076

From azafari at openjdk.org  Wed Nov 19 09:44:50 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 19 Nov 2025 09:44:50 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v22]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <MkZ6rJGto34avEqsTK_1tZSWsmirQSAZiaNwDGDw3X4=.b59e8d1d-0095-41f2-afa7-152bef68bb47@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NMT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  review comments applied

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27685/files
  - new: https://git.openjdk.org/jdk/pull/27685/files/d6cab2bd..f1c82747

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=20-21

  Stats: 157 lines in 8 files changed: 37 ins; 85 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/27685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685

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

From azafari at openjdk.org  Wed Nov 19 09:44:50 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 19 Nov 2025 09:44:50 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v22]
In-Reply-To: <MkZ6rJGto34avEqsTK_1tZSWsmirQSAZiaNwDGDw3X4=.b59e8d1d-0095-41f2-afa7-152bef68bb47@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <MkZ6rJGto34avEqsTK_1tZSWsmirQSAZiaNwDGDw3X4=.b59e8d1d-0095-41f2-afa7-152bef68bb47@github.com>
Message-ID: <0Dhjx6-2b1ULmihmAX_hruxfgKtcReprTz4XDBCTFHs=.5165ce52-6e31-42fa-9523-45b9ed626446@github.com>

On Wed, 19 Nov 2025 09:39:57 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NMT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments applied

Local ASAN build tests passed. Let's wait for GHA tests for non-ASAN builds.

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

PR Comment: https://git.openjdk.org/jdk/pull/27685#issuecomment-3551764716

From azafari at openjdk.org  Wed Nov 19 09:44:57 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 19 Nov 2025 09:44:57 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v21]
In-Reply-To: <In9nQGTMOLgKzmaZtgCg84w4GeExkXbKk9FoZsHYIw4=.9812cdd6-19fe-4cb8-9e40-9e73a859b831@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <2UfkSzuxH68EuDt0x5oY_Hy2Mxm3JT68vwTj9MXZW1w=.1e5c9ca2-bfb3-4ddd-82a7-6164516fd239@github.com>
 <In9nQGTMOLgKzmaZtgCg84w4GeExkXbKk9FoZsHYIw4=.9812cdd6-19fe-4cb8-9e40-9e73a859b831@github.com>
Message-ID: <vI4Ja4D2KpZXwDR04kEppySmQ08kbGZ-2Yqpe4RSYvk=.74dbf409-9526-4f97-98dc-e9b6c9af7172@github.com>

On Fri, 14 Nov 2025 11:04:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improvements.
>
> src/hotspot/share/sanitizers/address.hpp line 80:
> 
>> 78: 
>> 79: template<typename T>
>> 80: class AsanPoisoningHelper {
> 
> It would be preferable not to have it as a template, since one may want to use this with memory ranges whose sizes are not known at compile time. Just make the size a const member.
> 
> In addition to that, I am unsure we want to make it this easy to protect infinitesimal small memory ranges (e.g. uint16_t) before we have an idea of the overhead costs of every poison call. Especially if this is meant to be a general purpose class, not only for NMT malloc and free.

Template is removed. ctor gets ptr and size now.
Poisoning memory blocks is  as easy/difficult as calling `ASAN_POISON_MEMORY_REGION(ptr, size)` macro.

> src/hotspot/share/sanitizers/address.hpp line 81:
> 
>> 79: template<typename T>
>> 80: class AsanPoisoningHelper {
>> 81:   const T* _memory_region;
> 
> The pointer should be const.

I think I did not understand this comment. The pointer is already const. Which pointer do you refer to?

> src/hotspot/share/sanitizers/address.hpp line 85:
> 
>> 83:   AsanPoisoningHelper() = delete;
>> 84:   AsanPoisoningHelper(const T* addr) : _memory_region(addr) {
>> 85:     #if INCLUDE_ASAN
> 
> We use ADDRESS_SANITIZER in other places in this file, so I would use that.
> 
> In addition, I would wrap the whole class into ADDRESS_SANITIZER and not do this for the individual functions. And provide a simple stub for the non-ASAN case.

Done.

> test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 184:
> 
>> 182: 
>> 183: #else // ASAN is enabled
>> 184: 
> 
> Do we really need to duplicate this macro, just to give the test an own name? Certainly this can be simplified?

Fixed.

> test/hotspot/gtest/nmt/test_nmt_buffer_overflow_detection.cpp line 202:
> 
>> 200:   *canary_ptr = 1;
>> 201: }
>> 202: 
> 
> If we simplify to poisoning the whole header (or just the canary itself) this whole section can be shrunk down to two test functions.
> 
> Otherwise, there is a large potential for simplification here. A lot of that code is duplicated.
> 
> Also note that there is a time cost involved with very fine-grained tests like these. Death tests take a long time, since they involve forking new processes, starting the JVM, letting it crash, and writing the hs_err.log file. Seeing that we basically just test different offsets in the header, the usefulness of this many tests is questionable. 
> 
> I think I would reduce this to just one test, or maybe two if you want to be thorough and test both start and end of header. Arguably the only test really needed is the test for the canary, since it borders the user section directly and is the first to be hit on a buffer overflow.
> 
> As I wrote before: the section *preceding* the header is protected by ASAN anyway.

The extra tests removed. The number of tests are as {header, footer} x {read, write} x {realloc, malloc} == 8 cases now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2541239081
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2541260205
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2541254073
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2541239883
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2541247376

From jkratochvil at openjdk.org  Wed Nov 19 10:09:25 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Wed, 19 Nov 2025 10:09:25 GMT
Subject: RFR: 8372135: clang compilation error
In-Reply-To: <YguWkMOhsTo5KHK7BlV-z1-siGr1D6v11_0tLJAGpTQ=.83842d05-4f4e-4cc4-a9b7-dd81144215f3@github.com>
References: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
 <YguWkMOhsTo5KHK7BlV-z1-siGr1D6v11_0tLJAGpTQ=.83842d05-4f4e-4cc4-a9b7-dd81144215f3@github.com>
Message-ID: <7lvgxIVnmaJ4w6bZLyOSTgLNVelmo4OU3EzpzCDgUi0=.edcfee15-25f9-4c30-a023-7536ab425a50@github.com>

On Wed, 19 Nov 2025 09:09:51 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Please wait 24 hours before integrating. This is so that all contributors get a chance to see your PR.

OK for the future, I cannot remove the /integrate so that is for the committer now.

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

PR Comment: https://git.openjdk.org/jdk/pull/28384#issuecomment-3551860598

From azafari at openjdk.org  Wed Nov 19 10:11:15 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 19 Nov 2025 10:11:15 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v23]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <NXBuj08KJkPtl8ZkDtoDKyreBe1hn0rVF09_VsRns5Y=.6f2a07c2-459f-46c2-b3b8-9e8904c6e63e@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NMT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:

 - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer
 - review comments applied
 - improvements.
 - order of includes corrected.
 - fixes after merge.
 - Merge remote-tracking branch 'origin/master' into _20251006_asan_hdr_footer
 - review comments applied.
 - fixed problem after merge
 - Merge remote-tracking branch 'jdksjolen/test-canary' into _20251006_asan_hdr_footer
 - A different way
 - ... and 18 more: https://git.openjdk.org/jdk/compare/99135d2e...bc265745

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

Changes: https://git.openjdk.org/jdk/pull/27685/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=22
  Stats: 225 lines in 8 files changed: 185 ins; 5 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/27685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27685/head:pull/27685

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

From mbaesken at openjdk.org  Wed Nov 19 10:17:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 10:17:09 GMT
Subject: RFR: 8333871: check sysinfo return values [v3]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <dWoDleZzlIUEFhYnTXBzlwZxo8PQ4dtyVL9pbJ02n5k=.7054e3ee-a6d3-4e82-a2c1-983328de4f35@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

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

  use more asserts

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/e9d2b1b4..6284ef29

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

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

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

From mbaesken at openjdk.org  Wed Nov 19 10:17:11 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 10:17:11 GMT
Subject: RFR: 8333871: check sysinfo return values [v2]
In-Reply-To: <6wi89g5vMiAiGZzgljM43lQwsgOA5dc94LNBd64AktI=.5e954a04-6e28-4453-8bdd-4c7341a9fb69@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <FuNZXs2jEowUkQYEMCxFO2g7GdAKckC0MoAFkfEyPv8=.faebc296-16e1-4bcd-ae0b-eba5988516d4@github.com>
 <6wi89g5vMiAiGZzgljM43lQwsgOA5dc94LNBd64AktI=.5e954a04-6e28-4453-8bdd-4c7341a9fb69@github.com>
Message-ID: <Ki5GNjd8J2LL9SV0VqSjgzLwkMS8_kqyZCaDIuxfX-s=.7950c785-3469-4b27-b2d0-b2e6948744c5@github.com>

On Wed, 19 Nov 2025 07:57:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   0 - terminate not needed
>
> src/hotspot/os/linux/os_linux.cpp line 2594:
> 
>> 2592:   } else {
>> 2593:     st->print(", swap could not be determined");
>> 2594:   }
> 
> Again probably better to assert and say nothing, or use 0 as a placeholder.

Hi David, I added asserts where you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2541371007

From jsjolen at openjdk.org  Wed Nov 19 10:40:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 19 Nov 2025 10:40:40 GMT
Subject: RFR: 8372135: clang compilation error
In-Reply-To: <7lvgxIVnmaJ4w6bZLyOSTgLNVelmo4OU3EzpzCDgUi0=.edcfee15-25f9-4c30-a023-7536ab425a50@github.com>
References: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
 <YguWkMOhsTo5KHK7BlV-z1-siGr1D6v11_0tLJAGpTQ=.83842d05-4f4e-4cc4-a9b7-dd81144215f3@github.com>
 <7lvgxIVnmaJ4w6bZLyOSTgLNVelmo4OU3EzpzCDgUi0=.edcfee15-25f9-4c30-a023-7536ab425a50@github.com>
Message-ID: <zyVTFwbHJzGKc3XZ9aEcpQpzEsrNg9oC1giw_CxYWDk=.aa4a8b38-57ac-4d46-aa52-1062a484a4fa@github.com>

On Wed, 19 Nov 2025 10:05:21 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> > Please wait 24 hours before integrating. This is so that all contributors get a chance to see your PR.
> 
> OK for the future, I cannot remove the /integrate so that is for the committer now.

Yup, we'll wait with sponsoring until 24 hours has passed :-).

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

PR Comment: https://git.openjdk.org/jdk/pull/28384#issuecomment-3551988740

From aseoane at openjdk.org  Wed Nov 19 10:45:59 2025
From: aseoane at openjdk.org (Anton Seoane Ampudia)
Date: Wed, 19 Nov 2025 10:45:59 GMT
Subject: RFR: 8213762: Deprecate Xmaxjitcodesize
In-Reply-To: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
References: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
Message-ID: <ge1v_0bnGQ8QQftX0fb3NtLwojXJi3It2uEjXuufmdo=.962f41e4-20f0-460c-adef-fd3e0699dcb5@github.com>

On Thu, 13 Nov 2025 14:57:30 GMT, Anton Seoane Ampudia <aseoane at openjdk.org> wrote:

> This PR deprecates the `Xmaxjitcodesize` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behaviour in the future.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/28297#issuecomment-3552010483

From duke at openjdk.org  Wed Nov 19 10:46:00 2025
From: duke at openjdk.org (duke)
Date: Wed, 19 Nov 2025 10:46:00 GMT
Subject: RFR: 8213762: Deprecate Xmaxjitcodesize
In-Reply-To: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
References: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
Message-ID: <p-Pn3Y_Es1Ir9OPZsuq-In6qrWHjZgW7sByoPnHHSVE=.9e2453cb-569f-4d38-95c3-c1b6c2d4f8dc@github.com>

On Thu, 13 Nov 2025 14:57:30 GMT, Anton Seoane Ampudia <aseoane at openjdk.org> wrote:

> This PR deprecates the `Xmaxjitcodesize` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behaviour in the future.

@anton-seoane 
Your change (at version 07c96057a2a77ee3e59c93cf47b102ebc0033464) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/28297#issuecomment-3552016511

From azafari at openjdk.org  Wed Nov 19 10:48:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 19 Nov 2025 10:48:35 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v24]
In-Reply-To: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
Message-ID: <-dePf4_Xx0lhAl-KTFEX3i4VAzFivobZ0Jo1vMY7zCc=.f4c0eb29-405b-4ee6-9246-090bf554dd9a@github.com>

> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NMT checks the canaries and report error if they are not as expected.
> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  pragma fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27685/files
  - new: https://git.openjdk.org/jdk/pull/27685/files/bc265745..49d78559

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27685&range=22-23

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

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

From dholmes at openjdk.org  Wed Nov 19 11:46:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 11:46:57 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <QhOJeAWYUrTbk9uY_N1C7XzDFXVbhKBf8LhoFMiKHwI=.ff2784e4-8892-461e-8486-755fa28b26eb@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
 <3qBnky8giDXZXWtNaNoUJ2QIM7JBtXEbUHGaN0FjXbQ=.f0e1c86e-9f1d-4925-8928-0c0356ee6b09@github.com>
 <3l9QsqUQgEtZetyMGjHaWU_l6haVR6Nl6FedO6k6nmo=.0708fa57-9b53-47c8-81b7-bfb04c1a717a@github.com>
 <EOHIT24pLs9v2qn_Tmh5IyX6DYHBF4UdVIpQa0v4Unw=.4f915ba1-951c-45a5-8bb3-fb1a04dd69f5@github.com>
 <_0SVo1RDdcgs94gRaSNBRmI8qiI9a99SthkSSvCtoKQ=.5e032c5d-0790-4952-8dd1-83e9eacf0546@github.com>
 <QhOJeAWYUrTbk9uY_N1C7XzDFXVbhKBf8LhoFMiKHwI=.ff2784e4-8892-461e-8486-755fa28b26eb@github.com>
Message-ID: <dhyeXFFmNxp07ciwtAv4VcJzyIK0N5WcsStzeIav43s=.a8c66392-7904-40c0-82f2-de0e27e4dcb1@github.com>

On Wed, 19 Nov 2025 06:48:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Such a change will likely require spec changes about the meaning of System.out

Why? We are not changing anything about System.out. This is about where the VM writes stdout.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3552235300

From dholmes at openjdk.org  Wed Nov 19 11:46:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 11:46:59 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
Message-ID: <6kxOaRzqfn9zyK5hyjzwGeTnCbbcIachg8O8Y6sJHz0=.5767cb81-9ce7-4f15-b77c-ae027185d3d7@github.com>

On Sat, 15 Nov 2025 04:50:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
> 
> 
> try (var err = new PrintWriter(System.err);
>       var out = new PrintWriter(System.out)) {
>      out.println("Hello Confused World");
> }
> 
> 
> This has the side effect of closing the JVM's STDOUT.
> 
> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
> 
> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
> 
> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
> 
> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
> 
> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.

Anyway, this PR can workaround the issue - that is fine. I will file another issue to look at fixing the behaviour properly in the VM.

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3552238234

From mbaesken at openjdk.org  Wed Nov 19 12:34:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 12:34:43 GMT
Subject: RFR: 8333871: Check sysinfo return values [v4]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <uqLoUHT3pm7xIpY7tvqNAMxIqQAfjmmB-jzhoeMfh5U=.1b79dc7e-0c7a-4017-a18f-2e741337c065@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

Matthias Baesken 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 four additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8333871
 - use more asserts
 - 0 - terminate not needed
 - JDK-8333871

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/6284ef29..2f4c7c94

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

  Stats: 86 lines in 5 files changed: 67 ins; 6 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

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

From mbaesken at openjdk.org  Wed Nov 19 12:52:07 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 19 Nov 2025 12:52:07 GMT
Subject: RFR: 8333871: Check sysinfo return values [v5]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <3ykgR3X2ByYyZAPZQC594cFLuyhFYZr-9ZpsWR8I5A0=.20122600-a79f-4c0e-af46-53e11ec37e47@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge master
 - Merge remote-tracking branch 'origin/master' into JDK-8333871
 - use more asserts
 - 0 - terminate not needed
 - JDK-8333871

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

Changes: https://git.openjdk.org/jdk/pull/28317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28317&range=04
  Stats: 15 lines in 2 files changed: 8 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28317/head:pull/28317

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

From aseoane at openjdk.org  Wed Nov 19 13:04:26 2025
From: aseoane at openjdk.org (Anton Seoane Ampudia)
Date: Wed, 19 Nov 2025 13:04:26 GMT
Subject: Integrated: 8213762: Deprecate Xmaxjitcodesize
In-Reply-To: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
References: <TUsGbPl1Fi5qfVf_DUDYvCH6OHw4kVkvbU39T6pzAn8=.80ddd6f4-54bf-4c60-80cc-aea16b9742b8@github.com>
Message-ID: <mQaw6HRgMjCV1aTqZdCC36WugNWlQ8er-YNfu8XSF-U=.41bb2742-c551-4189-b8a9-f97e8387ed1b@github.com>

On Thu, 13 Nov 2025 14:57:30 GMT, Anton Seoane Ampudia <aseoane at openjdk.org> wrote:

> This PR deprecates the `Xmaxjitcodesize` flag in JDK 26. Please see the CSR for specific details on why this flag is being deprecated and workarounds for users interested in keeping similar behaviour in the future.

This pull request has now been integrated.

Changeset: 0bff5f3d
Author:    Anton Seoane Ampudia <aseoane at openjdk.org>
Committer: Emanuel Peter <epeter at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bff5f3dbe69ab2a59db771af1020b04c0132954
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8213762: Deprecate Xmaxjitcodesize

Reviewed-by: kvn, epeter

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

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

From duke at openjdk.org  Wed Nov 19 15:58:04 2025
From: duke at openjdk.org (David Beaumont)
Date: Wed, 19 Nov 2025 15:58:04 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
 [v2]
In-Reply-To: <a__MN_-K_Q5kCcgrJQRWXueVSte1VJ3lmK-RuZDKVuo=.7bc30023-288b-4a14-b1ff-ccf3b8705a6d@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
 <a__MN_-K_Q5kCcgrJQRWXueVSte1VJ3lmK-RuZDKVuo=.7bc30023-288b-4a14-b1ff-ccf3b8705a6d@github.com>
Message-ID: <1imWll3YdDqGJY6FiAjf9eHvwbwdyeK_w7BDVggLoSE=.f68f2736-a4ad-4492-8b01-adef48f9d35f@github.com>

On Tue, 4 Nov 2025 17:00:02 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly initialize location

LGTM - but I'm not a code owner.

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

Marked as reviewed by david-beaumont at github.com (no known OpenJDK username).

PR Review: https://git.openjdk.org/jdk/pull/28098#pullrequestreview-3483528061

From aartemov at openjdk.org  Wed Nov 19 16:04:51 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 19 Nov 2025 16:04:51 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Refactored tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/8c82d39c..08b481cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=11-12

  Stats: 388 lines in 5 files changed: 112 ins; 255 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Wed Nov 19 16:04:55 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Wed, 19 Nov 2025 16:04:55 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
 <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
Message-ID: <JuQz_Bq3gav3r6pmzdt_DeIY_vZItvsbjqpD0jj2-Ic=.6baf7706-c626-47b6-a693-240078d1c05f@github.com>

On Wed, 19 Nov 2025 04:55:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Added bool arg to notify_contended_enter
>
> Thank you for refactoring the test into several tests which share a common part. It is nice!
> May I ask you about more refactoring? I'll inline my comments with the refactoring suggestions.

> @sspitsyn the proposed changes do have an effect on the order of jvmti events posted. For instance, in the timed-out case:
> 
> Master branch, events posted: wait -> waited -> contended enter -> contended entered This PR: events posted: wait -> contended enter -> contended entered -> waited
> 
> I have checked the specs, and it is not really clear: is (re)entering the OM considered to be a part of `wait` or not?

@sspitsyn could you please comment on the order of events and possible issues we can get if the order is changed?

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 218:
> 
>> 216: 
>> 217:         return 0;
>> 218:     }
> 
> Nit: Launch of `Waiter` and `Resumer`, some testing steps and test shutdown are identical for all 3 tests. So, they can be factored out into separate functions located in the base file.

Thanks, I have applied a bit more refactoring, trying to move common stuff into the base test class.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3553429559
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2542591879

From iveresov at openjdk.org  Wed Nov 19 18:09:30 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Wed, 19 Nov 2025 18:09:30 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
Message-ID: <dGSOpgf68YE-5KZsy6zv5AAf9_aB0WFR3XEgv31x2Qk=.8f1cfa44-4451-4f6d-a5c3-e6b7f09e3032@github.com>

On Sat, 15 Nov 2025 04:50:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
> 
> 
> try (var err = new PrintWriter(System.err);
>       var out = new PrintWriter(System.out)) {
>      out.println("Hello Confused World");
> }
> 
> 
> This has the side effect of closing the JVM's STDOUT.
> 
> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
> 
> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
> 
> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
> 
> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
> 
> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.

Marked as reviewed by iveresov (Reviewer).

Marked as reviewed by iveresov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28335#pullrequestreview-3484055038
PR Review: https://git.openjdk.org/jdk/pull/28335#pullrequestreview-3484057678

From sspitsyn at openjdk.org  Wed Nov 19 18:12:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 18:12:12 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
Message-ID: <0LholCkfab5s73jB3elCViYiI2xdxjvCV-qjfXz7v4c=.837deadf-cfff-4b29-97bc-f859fbf9578b@github.com>

On Wed, 19 Nov 2025 16:04:51 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Refactored tests.

Thank you for update!

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 141:

> 139: 
> 140: 
> 141: 

Nit: unneeded empty lines

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait2.java line 156:

> 154: 
> 155: 
> 156: 

Nit: unneeded empty lines

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait3.java line 166:

> 164: 
> 165: 
> 166: 

Nit: unneeded empty lines

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3484035013
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543018144
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543018979
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543019514

From sspitsyn at openjdk.org  Wed Nov 19 19:11:02 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Nov 2025 19:11:02 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v12]
In-Reply-To: <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <CV8rFA60WkC70c6izsIeYaEEV11ap8IezQidIisa59I=.0888437d-e3e6-4eea-bf80-de95553c3d25@github.com>
 <Mne5gLwAfMtMw9WjrHfie_PCjvmCqma4S7h_QnlTC6M=.b60d9307-69ef-4169-930e-95009aedff15@github.com>
Message-ID: <aup3c3reezY0DRErSMxvq0Gx6BMK5t2-doScxFKCdGs=.8e4529c1-879d-4bb6-8f8f-95e08c422542@github.com>

On Wed, 19 Nov 2025 04:55:05 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Added bool arg to notify_contended_enter
>
> Thank you for refactoring the test into several tests which share a common part. It is nice!
> May I ask you about more refactoring? I'll inline my comments with the refactoring suggestions.

> @sspitsyn the proposed changes do have an effect on the order of jvmti events posted. For instance, in the timed-out case:
> Master branch, events posted: wait -> waited -> contended enter -> contended entered
> This PR: events posted: wait -> contended enter -> contended entered -> waited
> 
> I have checked the specs, and it is not really clear: is (re)entering the OM considered to be a part of wait or not?

I also do not see anything in the specs (JLS, JVMS and JVMTI) but I feel it is better to keep the original order if possible.
It is going to be an impact/change on the thread state:
  https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetThreadState

AFAIU, with this change new combinations of thread state bits will be observable:
  `JVMTI_THREAD_STATE_WAITING` + `JVMTI_THREAD_STATE_BLOCKED_ON_MONITOR_ENTER`
  + (`JVMTI_THREAD_STATE_WAITING_INDEFINITELY` | `JVMTI_THREAD_STATE_WAITING_WITH_TIMEOUT`)

Also, it is a change in behavior with a compatibility risk involved. So, a CSR will be needed for this change.
I'm not sure yet if we need to consult with the JCK team on this if no JCK tests are failed.

What mach5 tests did you run? In this case, it is more safe to run mach5 tiers 1-6.
@dholmes-ora may have some concerns here.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3554220528

From kbarrett at openjdk.org  Wed Nov 19 20:12:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 19 Nov 2025 20:12:53 GMT
Subject: RFR: 8372196: Compile error in cgroup code on Linux when using clang
 after JDK-8365606
Message-ID: <vidNR-CybcXQ_yuftIqbXRoiesaR74HX-xVtd0hn4wo=.e2b7d136-c8d7-4ac6-b118-1f6c95358639@github.com>

Please review this trivial fix for a build failure when using clang on Linux.

Testing: mach5 tier1 on linux. Local build with clang19 on linux-aarch64.

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

Commit messages:
 - add missing override specifieres

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

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

From kbarrett at openjdk.org  Wed Nov 19 20:52:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 19 Nov 2025 20:52:56 GMT
Subject: RFR: 8372196: Compile error in cgroup code on Linux when using
 clang after JDK-8365606
In-Reply-To: <vidNR-CybcXQ_yuftIqbXRoiesaR74HX-xVtd0hn4wo=.e2b7d136-c8d7-4ac6-b118-1f6c95358639@github.com>
References: <vidNR-CybcXQ_yuftIqbXRoiesaR74HX-xVtd0hn4wo=.e2b7d136-c8d7-4ac6-b118-1f6c95358639@github.com>
Message-ID: <xjO6kQFtFDS1kskKjXU04OOYw_DgcXfp36erObkTIaw=.234b783d-3519-4003-a1d2-fb9a049d4326@github.com>

On Wed, 19 Nov 2025 20:03:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix for a build failure when using clang on Linux.
> 
> Testing: mach5 tier1 on linux. Local build with clang19 on linux-aarch64.

Already covered by https://bugs.openjdk.org/browse/JDK-8372135

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

PR Comment: https://git.openjdk.org/jdk/pull/28402#issuecomment-3554578547

From kbarrett at openjdk.org  Wed Nov 19 20:52:56 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 19 Nov 2025 20:52:56 GMT
Subject: Withdrawn: 8372196: Compile error in cgroup code on Linux when using
 clang after JDK-8365606
In-Reply-To: <vidNR-CybcXQ_yuftIqbXRoiesaR74HX-xVtd0hn4wo=.e2b7d136-c8d7-4ac6-b118-1f6c95358639@github.com>
References: <vidNR-CybcXQ_yuftIqbXRoiesaR74HX-xVtd0hn4wo=.e2b7d136-c8d7-4ac6-b118-1f6c95358639@github.com>
Message-ID: <nBYjSzX_rgB1l4Ippxm3GYBOadHwhzxcvaPUfaE-_Ds=.f277fcdb-b556-416a-8271-07c6dddf1b3f@github.com>

On Wed, 19 Nov 2025 20:03:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix for a build failure when using clang on Linux.
> 
> Testing: mach5 tier1 on linux. Local build with clang19 on linux-aarch64.

This pull request has been closed without being integrated.

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

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

From iklam at openjdk.org  Wed Nov 19 21:01:03 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Nov 2025 21:01:03 GMT
Subject: RFR: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
 <7ez42Sq9WoFcNjEQk48KDbYZLj025veaqdUJGv_5QRU=.9c1cdb9e-e127-4cff-b487-6372e7d0a84b@github.com>
Message-ID: <aYJatI6Dm8FXWuxoNR4SgarX9Yfu9d4T7kojTjekdI8=.1c6a933f-b73c-4ca3-aa77-74f5edcf13af@github.com>

On Sat, 15 Nov 2025 05:34:32 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
>> 
>> 
>> try (var err = new PrintWriter(System.err);
>>       var out = new PrintWriter(System.out)) {
>>      out.println("Hello Confused World");
>> }
>> 
>> 
>> This has the side effect of closing the JVM's STDOUT.
>> 
>> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
>> 
>> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
>> 
>> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
>> 
>> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
>> 
>> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.
>
> The fix seems fine for this case.
> 
> VM itself may open a lot of files for different logs (JFR, JIT logs, UL, etc). May VM close some before you open AOT file which could cause the same issue? Is it possible to track life time of such files to make sure we don't write into them after they are closed?

Thanks @vnkozlov @veresov for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28335#issuecomment-3554604701

From iklam at openjdk.org  Wed Nov 19 21:01:06 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 19 Nov 2025 21:01:06 GMT
Subject: Integrated: 8371944: AOT configuration is corrupted when app closes
 System.out
In-Reply-To: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
References: <pGJMblJLUdq0TAeWcQ9kJiLHdMpmMaMGoGmhWDOuJWo=.93a1193b-36d3-44c2-b60e-f610d212dae4@github.com>
Message-ID: <a4lBYsGhh0RozHNsSzmemF-HkqoaU61_GFDPs1YqyOQ=.24e3f208-7d97-4463-9f43-da6567f981d2@github.com>

On Sat, 15 Nov 2025 04:50:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> During an AOT training run, some application may close `System.out` (usually inadvertently by naive code like the following):
> 
> 
> try (var err = new PrintWriter(System.err);
>       var out = new PrintWriter(System.out)) {
>      out.println("Hello Confused World");
> }
> 
> 
> This has the side effect of closing the JVM's STDOUT.
> 
> When the JVM is about to exit, we will open the AOT configuration file for writing. On Windows we may get back a file HANDLE (which is just an integer) that's identical to the now closed STDOUT.
> 
> If the JVM writes to STDOUT (usually with UL logging), it will corrupt the contents of the AOT configuration file.
> 
> This doesn't happen on Posix as `System.out.close()` will keep file descriptions 1 and 2 open, preventing them from being reused by files that are opened in the future.
> 
> The fix is to open the AOT configuration file early, before any application code is executed. That way we can guarantee that we will have a file HANDLE (or file descriptor) that's different than STDOUT.
> 
> The test failed failed about 20% of the time on Windows before the fix. After the fix, it ran 100 times without failure.

This pull request has now been integrated.

Changeset: 1535d08f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1535d08f0ee5da42d9db9e196d6a620aabe9feea
Stats:     130 lines in 6 files changed: 117 ins; 9 del; 4 mod

8371944: AOT configuration is corrupted when app closes System.out

Reviewed-by: kvn, iveresov

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

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

From kbarrett at openjdk.org  Wed Nov 19 21:00:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 19 Nov 2025 21:00:53 GMT
Subject: RFR: 8372135: clang compilation error
In-Reply-To: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
References: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
Message-ID: <sNGD9NjKsxFX9rD7-TlmHx_n_3pyWeU_2Bparn4NM24=.09b0b495-1e79-4c2b-ab80-70a25220fff2@github.com>

On Wed, 19 Nov 2025 07:59:32 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> clang-20.1.8-4.fc42.x86_64
> 
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:212:10: error: 'is_containerized' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   212 |     bool is_containerized();
>       |          ^       
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:284:18: note: overridden virtual function is here
>   284 |     virtual bool is_containerized() = 0;
>       |                  ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:214:18: error: 'container_type' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   214 |     const char * container_type() {
>       |                  ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:288:26: note: overridden virtual function is here
>   288 |     virtual const char * container_type() = 0;
>       |                          ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:217:54: error: 'memory_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   217 |     CachingCgroupController<CgroupMemoryController>* memory_controller() { return _memory; }
>       |                                                      ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:289:62: note: overridden virtual function is here
>   289 |     virtual CachingCgroupController<CgroupMemoryController>* memory_controller() = 0;
>       |                                                              ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:218:51: error: 'cpu_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   218 |     CachingCgroupController<CgroupCpuController>* cpu_controller() { return _cpu; }
>       |                                                   ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:290:59: note: overridden virtual function is here
>   290 |     virtual CachingCgroupController<CgroupCpuController>* cpu_controller() = 0;
>       |                                                           ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:219:30: error: 'cpuacct_controller' overrides a member function but is not marked...

Marked as reviewed by kbarrett (Reviewer).

FWIW, I would have been fine with approving this immediately as trivial and a build blocker.

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

PR Review: https://git.openjdk.org/jdk/pull/28384#pullrequestreview-3484717973
PR Comment: https://git.openjdk.org/jdk/pull/28384#issuecomment-3554596652

From dholmes at openjdk.org  Wed Nov 19 21:35:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 19 Nov 2025 21:35:47 GMT
Subject: RFR: 8369838: Likely invalid assert or function call in jimage.cpp
 [v2]
In-Reply-To: <a__MN_-K_Q5kCcgrJQRWXueVSte1VJ3lmK-RuZDKVuo=.7bc30023-288b-4a14-b1ff-ccf3b8705a6d@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
 <a__MN_-K_Q5kCcgrJQRWXueVSte1VJ3lmK-RuZDKVuo=.7bc30023-288b-4a14-b1ff-ccf3b8705a6d@github.com>
Message-ID: <QfVwgt8seW8msl5gFWLdg5hbNMdoQ8Q_XTikwSSMN4c=.6710bb10-205f-48bc-aff5-40e756a986c3@github.com>

On Tue, 4 Nov 2025 17:00:02 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly initialize location

I dug into the history of this but it was inconclusive. The correctness of the change boils down to the claim that the call with "" can never succeed. I don't know enough about the jimage file to verify that, but looking at the original commit there is nothing to suggest an empty module name is expected/valid, so I will defer to the testing that has been done here.

It might be worthwhile experimenting with JDK 9 to see if something was different back then.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28098#pullrequestreview-3484824542

From macarte at openjdk.org  Wed Nov 19 22:50:02 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 19 Nov 2025 22:50:02 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
Message-ID: <ozpNoQXXG8RwOb1rVoEiYx-AudsA8Cdru3GQhyeKV4g=.62b63951-f9bc-4380-84d9-266cef8f6f73@github.com>

On Fri, 14 Nov 2025 18:03:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 996:
> 
>> 994:     output()->print_cr("Error! Not a recording run");
>> 995:     return;
>> 996:   }
> 
> First, is `output()` directed to VM's tty or somewhere else?
> 
> Second, I think you need to be more verbose in error. Maybe:
> 
> Error: AOT recording is not initiated. VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing.

There are two cases:

1) When using jcmd the output is piped back from the VM to the jcmd process which in turn outputs the message to tty
2) When invoked using the DiagnosticCommandBean the output is piped back to the bean itself and returned as a string from the invoke method

These two cases are demonstrated in the included tests

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543798637

From lmesnik at openjdk.org  Wed Nov 19 22:57:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 19 Nov 2025 22:57:48 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
Message-ID: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>

On Wed, 19 Nov 2025 16:04:51 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Refactored tests.

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWaitWorker.java line 42:

> 40: 
> 41:     public void run() {
> 42:         SuspendWithObjectMonitorWait1.logDebug("thread running");

SuspendWithObjectMonitorWaitBase instead of SuspendWithObjectMonitorWait1 here.
There are a lot such places in this file.

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

PR Review: https://git.openjdk.org/jdk/pull/27040#pullrequestreview-3484952328
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2543738637

From macarte at openjdk.org  Wed Nov 19 22:58:09 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 19 Nov 2025 22:58:09 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <ozpNoQXXG8RwOb1rVoEiYx-AudsA8Cdru3GQhyeKV4g=.62b63951-f9bc-4380-84d9-266cef8f6f73@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
 <ozpNoQXXG8RwOb1rVoEiYx-AudsA8Cdru3GQhyeKV4g=.62b63951-f9bc-4380-84d9-266cef8f6f73@github.com>
Message-ID: <UM8rgf_uBB8xBLho_IeZycAx7qMhZDir8PMayW_Fy00=.0b84b9f4-ade9-4012-a730-8c10e9b82475@github.com>

On Wed, 19 Nov 2025 22:46:32 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/hotspot/share/services/diagnosticCommand.cpp line 996:
>> 
>>> 994:     output()->print_cr("Error! Not a recording run");
>>> 995:     return;
>>> 996:   }
>> 
>> First, is `output()` directed to VM's tty or somewhere else?
>> 
>> Second, I think you need to be more verbose in error. Maybe:
>> 
>> Error: AOT recording is not initiated. VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing.
>
> There are two cases:
> 
> 1) When using jcmd the output is piped back from the VM to the jcmd process which in turn outputs the message to tty
> 2) When invoked using the DiagnosticCommandBean the output is piped back to the bean itself and returned as a string from the invoke method
> 
> These two cases are demonstrated in the included tests

Updated the message, following convention and not including "Error! .."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543812881

From macarte at openjdk.org  Wed Nov 19 23:06:00 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 19 Nov 2025 23:06:00 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
Message-ID: <Ojzcli84zYO28bOe7qgAv8CIHNhptpcGrP2UzRZMGrQ=.68f2212c-153b-4b84-b738-aff0f3ac7298@github.com>

On Fri, 14 Nov 2025 18:12:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1000:
> 
>> 998:   if (!AOTMetaspace::is_recording_preimage_static_archive()) {
>> 999:     output()->print_cr("Error! Not recording");
>> 1000:     return;
> 
> This check is confusing because your error message is cryptic.
> Actually I think you don't need any message here - it is not error. Use comment instead:
> 
>   // The other thread already initiated end of recording.

I've changed the message to be less cryptic, but the message should still be returned to whoever invoked the command

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543825605

From macarte at openjdk.org  Thu Nov 20 00:46:28 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 00:46:28 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <zna2OnSwQQMwbSEB1v26mUIwXaGE3PKIFGwlpHeyfpA=.b0119c81-f055-4700-9426-ea01e3927802@github.com>
Message-ID: <60ObxggVqKu_dERxlWG1qDSXlvdxTfSFC-iFjpABKi8=.a6add8d8-9dc6-4275-956c-0f6137b0f5a0@github.com>

On Fri, 14 Nov 2025 18:25:03 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 1007:
> 
>> 1005:     output()->print_cr("Recording ended successfully");
>> 1006:     return;
>> 1007:   }
> 
> I think this should be reversed and message replaced with comment.
> 
> if (AOTMetaspace::is_recording_preimage_static_archive()) {
>     // Other thread already dumped archive.
>     return;
> }
> output()->print_cr("AOT recording ended successfully");

I switched the order, but the error condition stands:  we attempted to stop the recording, but the VM believes the recording is still continuing

Please note that the flag indicates that the recording is stopping/stopped but the cache may not have been dumped yet

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2543974788

From dholmes at openjdk.org  Thu Nov 20 05:03:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 05:03:11 GMT
Subject: RFR: 8333871: Check sysinfo return values [v5]
In-Reply-To: <3ykgR3X2ByYyZAPZQC594cFLuyhFYZr-9ZpsWR8I5A0=.20122600-a79f-4c0e-af46-53e11ec37e47@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <3ykgR3X2ByYyZAPZQC594cFLuyhFYZr-9ZpsWR8I5A0=.20122600-a79f-4c0e-af46-53e11ec37e47@github.com>
Message-ID: <_6HDANESo9PVzJPFr_stWvoBL3tB-Edv10EmoOKBW4k=.3cf0ecae-9532-45b4-8d7a-d9da35eb7c15@github.com>

On Wed, 19 Nov 2025 12:52:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge master
>  - Merge remote-tracking branch 'origin/master' into JDK-8333871
>  - use more asserts
>  - 0 - terminate not needed
>  - JDK-8333871

src/hotspot/os/linux/os_linux.cpp line 2436:

> 2434:     os::print_dhm(st, "OS uptime:", (long) sinfo.uptime);
> 2435:   }
> 2436:   assert(ret == 0, "sysinfo must return 0");

Sorry we should report the value of `errno` if the assert fails
Suggestion:

  assert(ret == 0, "sysinfo failed: %s", os::strerror(errno));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28317#discussion_r2544337803

From henryjen at openjdk.org  Thu Nov 20 05:34:20 2025
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 20 Nov 2025 05:34:20 GMT
Subject: Integrated: 8369838: Likely invalid assert or function call in
 jimage.cpp
In-Reply-To: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
References: <TCSujuQFaf7DJl9sMvuzLkoVB48u83MZGA_oG-nzZf0=.7f825c27-cb3b-4afd-85d0-a129de33f2af@github.com>
Message-ID: <jdWmV0L_hP8ThlVOfihcSExf_OAVWOiRmvUgNpRbvC0=.4bcaa0e8-785f-4ba0-a944-2911c0a1dc05@github.com>

On Sat, 1 Nov 2025 15:42:37 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> JVM should not attempt to load resource without module name. All classes loaded from jimage by the bootclassloader should have mapped into a module.

This pull request has now been integrated.

Changeset: 473471c1
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/473471c1f1d3cd42a057dfd602d452196c53aa00
Stats:     23 lines in 2 files changed: 1 ins; 2 del; 20 mod

8369838: Likely invalid assert or function call in jimage.cpp

Reviewed-by: dholmes

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

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

From dholmes at openjdk.org  Thu Nov 20 05:42:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 05:42:02 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
Message-ID: <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>

On Wed, 19 Nov 2025 22:55:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> Changes requested by lmesnik (Reviewer).

@lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern. That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself. Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.

Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the `monitor_waited` event would be posted whilst the thread is still suspended. To be clear(er) in the old code we would do:

wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor

whereas the new code, if we kept the placement of the event,  would do

wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor

and what the proposed code actually does is

wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor -> post monitor_waited 


Given the lack of specificity in the JVM TI spec around these different events I think any assumptions in a TCK test could be challenged, but it would still be a change in behaviour.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3555943800

From jsjolen at openjdk.org  Thu Nov 20 07:12:40 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 20 Nov 2025 07:12:40 GMT
Subject: Integrated: 8355225: Test gtest/AsyncLogGtest.java failed at
 droppingMessage_vm: apparent log corruption
In-Reply-To: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
References: <zW5Un3f_DK0P1IvLRl_Fcc8CYZyLNOEy81zCsa1McBs=.7d3969e3-492c-416d-9c65-a751ee72b6d4@github.com>
Message-ID: <cc8FjPGWQhv9Bnxv-L69V_xp1heKumVStUzXknVBq90=.3176c2bc-a25e-4e91-93f5-4e924c876ab0@github.com>

On Tue, 18 Nov 2025 15:12:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> We've intermittently seen failures from this test. The testing of the actual semantics of dropping async messages is done throughout the entire test file, and then we have a specific test called `droppingMessage`. Certainly, this is a bit unexpected, and perhaps not what we want. What I did find, however, is that this test doesn't follow the same pattern as the other ones that do the drop message testing.
> 
> The other tests do:
> 
> 
>     test_asynclog_drop_messages();
>     AsyncLogWriter::flush(); // <- Insert a flush token to the AsyncLogWriter buffer and await for it to be written
>     fflush(nullptr); // <- Force all libc writes to be performed
> 
> 
> And the `droppingMessage` test only does `test_asynclog_drop_messages();` .
> 
> I'd like us to just insert these two lines and see whether this affects what we see in our testing. This doesn't explain the so-called 'log corruption' when we try to read the content. The best explanation (read: guess) I have for that is that we're concurrently reading and writing to the file, and this leads to data races between the reads and writes.
> 
> Thanks.
> 
> Testing: GHA

This pull request has now been integrated.

Changeset: 72c45a4d
Author:    Johan Sj?len <jsjolen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72c45a4d923a294108995e24951bec24dfc70410
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8355225: Test gtest/AsyncLogGtest.java failed at droppingMessage_vm: apparent log corruption

Reviewed-by: dholmes, syan

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

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

From dholmes at openjdk.org  Thu Nov 20 07:15:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 07:15:10 GMT
Subject: RFR: 8371762: Incorrect use of checked_cast in
 Arguments::process_settings_file
In-Reply-To: <fI3YSAZfE0YWoISEl8PjD6k2ljs1Dg0Rz6-PSCbHAz8=.efc8d2a0-443e-4535-be5a-fa90a33b8f3f@github.com>
References: <fI3YSAZfE0YWoISEl8PjD6k2ljs1Dg0Rz6-PSCbHAz8=.efc8d2a0-443e-4535-be5a-fa90a33b8f3f@github.com>
Message-ID: <2l9L7S0VcipTDtGBVXVnjlLRMPAy_oh0mLCtk8awWOY=.a4ac6400-34e8-4b75-8b44-78a8ec213690@github.com>

On Thu, 13 Nov 2025 07:14:29 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> [JDK-8313882](https://bugs.openjdk.org/browse/JDK-8313882) introduced a `checked_cast` when to silence the Wconversion warnings when we store an `int` in a `char`. The problem is that the assumption that the value in the `int` we get from `getc` is compatible with `char` is incorrect.
> 
> The specification for `getc` is that it returns either `EOF` or the next read `unsigned char` converted to an `int`. This means we have the possible values of `{EOF, 0-255}`, we always check for `EOF` first, so we end up only having `{0-255}` as the possible values. (While a char has the possible values of `{-128-127}`.)
> 
> So first the problem with `checked_cast` (which ensures that the type roundtrip is lossless) will end up converting any value in `{128-255}` to `{-128, -1}` which when converted back to an `int` is `{-128, -1}` and not `{128-255}`.
> 
> The thing is that this is not a problem except for the assert as we do not care if the conversion roundtrip is lossless. We only want to reinterpret the value as a `char`, and never try to regain the unsigned representation converted to an `int` that `getc` uses.
> 
> Another issue with keeping the value inside an `int` which could lead to bugs in the future is that when we use it in equality comparison agains a `char` we will encounter an integer promotion of the `char` which will lead to surprising incorrect results if the character is non-ascii.
> 
> Currently we have no such comparisons of this `int` vs a non-ascii character. So the only issue is the assert inside `checked_cast` which will trigger if the settings file contains a non-ascii character.
> 
> I suggest we convert the return value from `getc` to a `char` after we have check for `EOF` and before we use it as a character.
> 
> It is worth noting that the `(unsigned char)` casts for the calls into `isspace` (introduced by [JDK-8332400](https://bugs.openjdk.org/browse/JDK-8332400)) is very important to get the correct value for its `int` input parameter. (So we get the correct non-sign extended cast `char -> unsigned char -> int`.) That issue mentions the possibility of introducing our own `isspace` (suggestion was `os::isspace`) which we could overload the different types and do the correct thing with bound checks. This might be something we want to revisit.
> 
> _`isspace` specification:_
>>The behavior is undefined if the value of ch is not representable as unsigned char and is not equal to [EOF](https://en.cppreference.com/w/c/io.html).
> 
> * Testing
>   * GHA
>   * Running tier 1-3 on Oracl...

I have to say I have never seen code take such elaborate steps in using `getc`. The idiomatic pattern is just:

int ch;
char* buf = ...;
...
while ((ch = getc(fp)) != EOF) {
  *buf++ = (char) ch;
}

As you note the result of `getc` is either EOF i.e. -1 ie. 0xFFFFFFFF, or else an unsigned char with the bit pattern 0x00000000 to 0x000000FF. If we C-cast such a value to a char (or unsigned char) I expect the bit pattern of the lower 8-bits to be unchanged either way.  I've looked at standards and "scoured the internet" and while I can't find any example of using `getc` in such an elaborate way (the double cast), I also can't find a clear answer that it is not indeed necessary to be so elaborate!

src/hotspot/share/runtime/arguments.cpp line 1228:

> 1226: 
> 1227:   int c_or_eof = getc(stream);
> 1228:   while(c_or_eof != EOF && pos < (int)(sizeof(token)-1)) {

Suggestion:

  while (c_or_eof != EOF && pos < (int)(sizeof(token) - 1)) {

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

PR Review: https://git.openjdk.org/jdk/pull/28283#pullrequestreview-3485906536
PR Review Comment: https://git.openjdk.org/jdk/pull/28283#discussion_r2544515895

From aboldtch at openjdk.org  Thu Nov 20 08:23:10 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 08:23:10 GMT
Subject: RFR: 8371762: Incorrect use of checked_cast in
 Arguments::process_settings_file [v2]
In-Reply-To: <fI3YSAZfE0YWoISEl8PjD6k2ljs1Dg0Rz6-PSCbHAz8=.efc8d2a0-443e-4535-be5a-fa90a33b8f3f@github.com>
References: <fI3YSAZfE0YWoISEl8PjD6k2ljs1Dg0Rz6-PSCbHAz8=.efc8d2a0-443e-4535-be5a-fa90a33b8f3f@github.com>
Message-ID: <jzzpxOrjyg6KNDOq4050C-pfngfyi8lcyfLZyK0LilI=.1b84e6a7-3aff-4047-9073-4ae6d9675e17@github.com>

> [JDK-8313882](https://bugs.openjdk.org/browse/JDK-8313882) introduced a `checked_cast` when to silence the Wconversion warnings when we store an `int` in a `char`. The problem is that the assumption that the value in the `int` we get from `getc` is compatible with `char` is incorrect.
> 
> The specification for `getc` is that it returns either `EOF` or the next read `unsigned char` converted to an `int`. This means we have the possible values of `{EOF, 0-255}`, we always check for `EOF` first, so we end up only having `{0-255}` as the possible values. (While a char has the possible values of `{-128-127}`.)
> 
> So first the problem with `checked_cast` (which ensures that the type roundtrip is lossless) will end up converting any value in `{128-255}` to `{-128, -1}` which when converted back to an `int` is `{-128, -1}` and not `{128-255}`.
> 
> The thing is that this is not a problem except for the assert as we do not care if the conversion roundtrip is lossless. We only want to reinterpret the value as a `char`, and never try to regain the unsigned representation converted to an `int` that `getc` uses.
> 
> Another issue with keeping the value inside an `int` which could lead to bugs in the future is that when we use it in equality comparison agains a `char` we will encounter an integer promotion of the `char` which will lead to surprising incorrect results if the character is non-ascii.
> 
> Currently we have no such comparisons of this `int` vs a non-ascii character. So the only issue is the assert inside `checked_cast` which will trigger if the settings file contains a non-ascii character.
> 
> I suggest we convert the return value from `getc` to a `char` after we have check for `EOF` and before we use it as a character.
> 
> It is worth noting that the `(unsigned char)` casts for the calls into `isspace` (introduced by [JDK-8332400](https://bugs.openjdk.org/browse/JDK-8332400)) is very important to get the correct value for its `int` input parameter. (So we get the correct non-sign extended cast `char -> unsigned char -> int`.) That issue mentions the possibility of introducing our own `isspace` (suggestion was `os::isspace`) which we could overload the different types and do the correct thing with bound checks. This might be something we want to revisit.
> 
> _`isspace` specification:_
>>The behavior is undefined if the value of ch is not representable as unsigned char and is not equal to [EOF](https://en.cppreference.com/w/c/io.html).
> 
> * Testing
>   * GHA
>   * Running tier 1-3 on Oracl...

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/runtime/arguments.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28283/files
  - new: https://git.openjdk.org/jdk/pull/28283/files/6deed6fb..8d9337d4

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

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

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

From mbaesken at openjdk.org  Thu Nov 20 08:27:43 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 20 Nov 2025 08:27:43 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

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

  Better assert messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28317/files
  - new: https://git.openjdk.org/jdk/pull/28317/files/e498891b..22a2f6aa

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

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

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

From aboldtch at openjdk.org  Thu Nov 20 09:13:25 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 09:13:25 GMT
Subject: RFR: 8372242: Gtest LogTagSet.defaults should run in OTHER VM
Message-ID: <bw7-kyaN8SOAG0DJc6iO9gt29Qjm4jDtu3FCkCCzEOM=.b6dda0c2-8939-4342-b208-b810e51cfa28@github.com>

LogTagSet.defaults checks some of the default `LogTagSet` properties and assumes a fresh VM. This test will fail if the other `LogTagSet` have run first.

As this test is ment to test the defaults of the LogTagSet, it should be ran in an OTHER VM. 

We might still have problems if logging flags are given to the GTestLauncher. But all our jtreg GTest runners are `@requires vm.flagless`, so this should only occur when running very custom test invocations.

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

Depends on: https://git.openjdk.org/jdk/pull/28409

Commit messages:
 - Gtest LogTagSet.defaults should run in OTHER VM

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

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

From jsjolen at openjdk.org  Thu Nov 20 09:13:26 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 20 Nov 2025 09:13:26 GMT
Subject: RFR: 8372242: Gtest LogTagSet.defaults should run in OTHER VM
In-Reply-To: <bw7-kyaN8SOAG0DJc6iO9gt29Qjm4jDtu3FCkCCzEOM=.b6dda0c2-8939-4342-b208-b810e51cfa28@github.com>
References: <bw7-kyaN8SOAG0DJc6iO9gt29Qjm4jDtu3FCkCCzEOM=.b6dda0c2-8939-4342-b208-b810e51cfa28@github.com>
Message-ID: <krDkZv-waSyPbQkXm7X83VfVvV4ufhdX0Kb-EeczZvM=.b2443ac5-a230-4a74-aa18-0ebe3aecc6eb@github.com>

On Thu, 20 Nov 2025 09:03:42 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> LogTagSet.defaults checks some of the default `LogTagSet` properties and assumes a fresh VM. This test will fail if the other `LogTagSet` have run first.
> 
> As this test is ment to test the defaults of the LogTagSet, it should be ran in an OTHER VM. 
> 
> We might still have problems if logging flags are given to the GTestLauncher. But all our jtreg GTest runners are `@requires vm.flagless`, so this should only occur when running very custom test invocations.

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28411#pullrequestreview-3486516303

From aboldtch at openjdk.org  Thu Nov 20 09:17:21 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 09:17:21 GMT
Subject: RFR: 8372243: ZGC: ZForwardingTest.find_every_other is mistaken for a
 other VM gtest
Message-ID: <sUhmeUbJ-nFVj36tBsWQHp9XxnkmlnKr1jirU4kfFrY=.a97e563e-6ad7-467e-8ef0-00f3d2fdb291@github.com>

The current implementation of our GTest runner identifies the category of test by the suffix it adds.
This is either `_vm`, `_other_vm` or `_vm_assert`. This is problematic for `ZForwardingTest.find_every_other` which is a VM test and ends up with the final name `ZForwardingTest.find_every_other_vm` and is mistaken for an other VM test in the filters, but is run as a VM test. Currently `ZForwardingTest.find_every_other` if another VM test has been ran first.

I propose we enhance our GTest category naming to make this thing impossible by:
1. Change `_vm`, `_other_vm` and `_vm_assert` to `__vm`, `__other_vm` and `__vm_assert`
2. Fail to compile tests which end in `_`, `__vm`, `__other_vm` or `__vm_assert`

Note that this patch uses an undecided hotspot feature in the gtest launcher `std::string_view`.
It would be very unfortunate to not be able to use this feature, as without it (or a similar construction) performing static checking of strings and sub-strings is rather cumbersome.

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

Depends on: https://git.openjdk.org/jdk/pull/28409

Commit messages:
 - ZGC: ZForwardingTest.find_every_other is mistaken for a other VM gtest

Changes: https://git.openjdk.org/jdk/pull/28412/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28412&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372243
  Stats: 41 lines in 7 files changed: 18 ins; 6 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28412/head:pull/28412

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

From duke at openjdk.org  Thu Nov 20 09:28:30 2025
From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=)
Date: Thu, 20 Nov 2025 09:28:30 GMT
Subject: RFR: 8372253: Improve logging to show why a class was excluded form
 AOT Cache
Message-ID: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>

Fixes: https://bugs.openjdk.org/browse/JDK-8372253

When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:


[warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
[warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification


This PR improves the log message by adding the cause of this failure:


[warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod

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

Commit messages:
 - JDK-8372253: Add the exception to the log message

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

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

From aboldtch at openjdk.org  Thu Nov 20 09:30:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 09:30:03 GMT
Subject: RFR: 8372246: LogOutputList gtests should not use LogConfiguration
 LogOutputs
Message-ID: <wopRTmbbbEEBIITHdSw_Ocdg6qAe2Jz3sRaX8LVRYEk=.fbea1965-d674-4ee5-ae3b-780f6de9fd82@github.com>

A handful of `LogOutputList` tests uses `LogConfiguration::Std[out|err]Log` LogOutputs in its tests.
However these are not setup unless we run the tests in VM mode.

I suggest we add some dummy `LogOutputs` for `StdoutLog` and `StderrLog` which these tests can use, so they are not depending being a VM test.

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

Depends on: https://git.openjdk.org/jdk/pull/28409

Commit messages:
 - LogOutputList gtests should not use LogConfiguration LogOutputs

Changes: https://git.openjdk.org/jdk/pull/28416/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28416&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372246
  Stats: 26 lines in 2 files changed: 10 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28416/head:pull/28416

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

From aboldtch at openjdk.org  Thu Nov 20 09:32:11 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 09:32:11 GMT
Subject: RFR: 8372247: OSX: Semaphore.trywait requires os::Bsd::clock_init
Message-ID: <eVakkuHWTHGDS0VJIu85hHuVfhNppo37w0HOwFV0tXs=.5c5d33eb-a525-44f2-9f45-d360ca226377@github.com>

The OSX implementation of the Semaphore requires `os::javaTimeNanos` which requires that we have initiated the clocks via `os::Bsd::clock_init()`. Or we will get an integer division by zero when performing a trywait.

I propose that we let this test setup `os::Bsd::clock_init()` rather than being forced to run in VM.

An alternative would be to simply run this test in VM. Making the dependency more clear. Or only use VM for `__APPLE__`.

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

Depends on: https://git.openjdk.org/jdk/pull/28409

Commit messages:
 - OSX: Semaphore.trywait requires os::Bsd::clock_init

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

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

From aartemov at openjdk.org  Thu Nov 20 09:54:31 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 09:54:31 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v14]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <INXjf-VAnwQeVCl0B2--wxt0OI5RJwyPjfw8WMpaFZ4=.c6c23007-7f8d-43a1-b503-3e64c41d7400@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:

 - 8366659: Fixed tests.
 - 8366659: Fixed tests.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/08b481cd..5fe2d506

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=12-13

  Stats: 46 lines in 5 files changed: 0 ins; 12 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Thu Nov 20 09:54:34 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 09:54:34 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
Message-ID: <LCH0r3k_oYZ9aUaicYi0jQfLaZYOvNksUrqQsLPsxtE=.dfa50e6c-ca84-4bb0-a416-5adab07c98e0@github.com>

On Wed, 19 Nov 2025 22:55:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> Changes requested by lmesnik (Reviewer).

> @lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern. That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself. Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.

I think this comment was supposed to be addressed to @sspitsyn

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWaitWorker.java line 42:
> 
>> 40: 
>> 41:     public void run() {
>> 42:         SuspendWithObjectMonitorWait1.logDebug("thread running");
> 
> SuspendWithObjectMonitorWaitBase instead of SuspendWithObjectMonitorWait1 here.
> There are a lot such places in this file.

Thanks for spotting this! Yes, `SuspendWithObjectMonitorWaitWorker` used to live in the same file as the original test and I forgot to update the names. Fixed now.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3556945962
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545160721

From aartemov at openjdk.org  Thu Nov 20 09:54:38 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 09:54:38 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <0LholCkfab5s73jB3elCViYiI2xdxjvCV-qjfXz7v4c=.837deadf-cfff-4b29-97bc-f859fbf9578b@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <0LholCkfab5s73jB3elCViYiI2xdxjvCV-qjfXz7v4c=.837deadf-cfff-4b29-97bc-f859fbf9578b@github.com>
Message-ID: <SBoR1d7YHImoV_tfUkVnfW2IXrtOP-_4VYluLTGO0n4=.33977b00-fcf7-4414-a3e5-2f566675f156@github.com>

On Wed, 19 Nov 2025 17:50:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait1.java line 141:
> 
>> 139: 
>> 140: 
>> 141: 
> 
> Nit: unneeded empty lines

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait2.java line 156:
> 
>> 154: 
>> 155: 
>> 156: 
> 
> Nit: unneeded empty lines

Addressed in the latest commit.

> test/hotspot/jtreg/serviceability/jvmti/SuspendWithObjectMonitorWait/SuspendWithObjectMonitorWait3.java line 166:
> 
>> 164: 
>> 165: 
>> 166: 
> 
> Nit: unneeded empty lines

Addressed in the latest commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545178592
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545178219
PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2545178072

From tschatzl at openjdk.org  Thu Nov 20 10:13:22 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 20 Nov 2025 10:13:22 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v4]
In-Reply-To: <shP2-MDXK_C_uOidBkPOXGOhul0ZMoWeFNj-smLcuPo=.a6e8de5a-4cf7-4360-98d2-2eb82d23592e@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <shP2-MDXK_C_uOidBkPOXGOhul0ZMoWeFNj-smLcuPo=.a6e8de5a-4cf7-4360-98d2-2eb82d23592e@github.com>
Message-ID: <rMfTnVzQbMp-JgoB3SOvxxOSGwTFtqn64DBIt1f9ZTQ=.41b302b1-5fde-4d0c-8ae9-71029bba59ac@github.com>

On Wed, 19 Nov 2025 07:21:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
>> 
>> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
>> 
>> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
>> 
>> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
>> 
>> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
>> 
>> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
>> 
>> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
>> 
>> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
>> 
>> There are some G1 specific details to look at:
>> 
>> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
>> 
>> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
>> 
>> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28349#pullrequestreview-3486839623

From cnorrbin at openjdk.org  Thu Nov 20 10:27:13 2025
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 20 Nov 2025 10:27:13 GMT
Subject: RFR: 8372125: containers/docker/TestPids.java fails after 8365606
In-Reply-To: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
References: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
Message-ID: <5JwtUs1o3VpnrW3whHc5ALeTdpVrSTNghNDp9Q-puTg=.f39a8e97-30a5-4ab4-9270-fa8e2ea9651d@github.com>

On Wed, 19 Nov 2025 03:20:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test containers/docker/TestPids.java seems to be fails after [JDK-8365606](https://bugs.openjdk.org/browse/JDK-8365606)
> I think max/-1/ulimited are all acceptable as unlimited pids value.
> The change has been verified locally on linux-x64 and linux-aarch64.

Looks good!

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

Marked as reviewed by cnorrbin (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28383#pullrequestreview-3486917284

From aartemov at openjdk.org  Thu Nov 20 10:42:35 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 10:42:35 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v15]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <uzaJTic7kpw0Aad1jvQZRPRC3R5qtoX_Zx87zhtmtfc=.d032a489-16e3-4182-b59c-d1e0c0596fc0@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - 8366659: Fixed tests.
 - 8366659: Fixed tests.
 - 8366659: Refactored tests.
 - 8366659: Added bool arg to notify_contended_enter
 - 8366659: Refactored the big test into 3 smaller tests.
 - 8366659: Addressed reviewer's comments.
 - 8366659: Addressed reviewer's comments.
 - 8366659: Addressed reviewer's comments.
 - Merge remote-tracking branch 'origin/master' into JDK-8366659-OM-wait-suspend-deadlock
 - ... and 21 more: https://git.openjdk.org/jdk/compare/ad38a125...9356cd9f

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

Changes: https://git.openjdk.org/jdk/pull/27040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=14
  Stats: 1238 lines in 9 files changed: 803 ins; 415 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From dholmes at openjdk.org  Thu Nov 20 11:46:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 11:46:16 GMT
Subject: RFR: 8372247: OSX: Semaphore.trywait requires os::Bsd::clock_init
In-Reply-To: <eVakkuHWTHGDS0VJIu85hHuVfhNppo37w0HOwFV0tXs=.5c5d33eb-a525-44f2-9f45-d360ca226377@github.com>
References: <eVakkuHWTHGDS0VJIu85hHuVfhNppo37w0HOwFV0tXs=.5c5d33eb-a525-44f2-9f45-d360ca226377@github.com>
Message-ID: <jdKx_Ec6b5aKGMcSn9ooUjx1Jws3g7o9ntoU48_13oM=.ed3acd28-34b3-4e29-a7cd-fcc3338db89c@github.com>

On Thu, 20 Nov 2025 09:25:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The OSX implementation of the Semaphore requires `os::javaTimeNanos` which requires that we have initiated the clocks via `os::Bsd::clock_init()`. Or we will get an integer division by zero when performing a trywait.
> 
> I propose that we let this test setup `os::Bsd::clock_init()` rather than being forced to run in VM.
> 
> An alternative would be to simply run this test in VM. Making the dependency more clear. Or only use VM for `__APPLE__`.

Seems fine to do this in the test.

I had no idea that internal "problem list" existed. Pity the associated bug reports are not listed with them.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28417#pullrequestreview-3487374365

From aboldtch at openjdk.org  Thu Nov 20 12:56:51 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 12:56:51 GMT
Subject: RFR: 8372247: OSX: Semaphore.trywait requires os::Bsd::clock_init
In-Reply-To: <jdKx_Ec6b5aKGMcSn9ooUjx1Jws3g7o9ntoU48_13oM=.ed3acd28-34b3-4e29-a7cd-fcc3338db89c@github.com>
References: <eVakkuHWTHGDS0VJIu85hHuVfhNppo37w0HOwFV0tXs=.5c5d33eb-a525-44f2-9f45-d360ca226377@github.com>
 <jdKx_Ec6b5aKGMcSn9ooUjx1Jws3g7o9ntoU48_13oM=.ed3acd28-34b3-4e29-a7cd-fcc3338db89c@github.com>
Message-ID: <Y7NiI9zFmLyT2q37F_KLx7AaQjRJVmi2GZuJCjs_-7Q=.9e6020c5-1396-4e5f-bf37-91a0aaac9b79@github.com>

On Thu, 20 Nov 2025 11:43:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I had no idea that internal "problem list" existed. 

I introduce it with #28409 / [JDK-8372241](https://bugs.openjdk.org/browse/JDK-8372241) which this PR depends on. So it is not in mainline yet.

> Pity the associated bug reports are not listed with them.

So I'll make sure to add the bug issues to the list. I had not filed the bug reports when I created the problem lists. I'll push an update with the linked bug ids to PR #28409

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

PR Comment: https://git.openjdk.org/jdk/pull/28417#issuecomment-3557907540

From phubner at openjdk.org  Thu Nov 20 13:11:28 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Thu, 20 Nov 2025 13:11:28 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v6]
In-Reply-To: <GHakO5HS_bBpXH6DIvfkhMpclt0fbzOjImFFHoJyHYk=.b0ccd55b-ec2f-42ab-8189-b7493f1edd60@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
 <GHakO5HS_bBpXH6DIvfkhMpclt0fbzOjImFFHoJyHYk=.b0ccd55b-ec2f-42ab-8189-b7493f1edd60@github.com>
Message-ID: <M6JyP0gIcJwY7naX0dKLc-Tj_EwGhQa5k4zPWSn4dPU=.f63c91c9-8acb-4d5a-b968-fc0cc4e7c5c9@github.com>

On Tue, 30 Sep 2025 10:09:35 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The structures `CommittedMemoryRegion` and `ReservedMemoryRegion` are merged into the `VirtualMemoryRegion`.
>> 
>> Tests:
>> tiers1-5, main platforms, debug/product
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>  - fixes
>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>  - master merge fix
>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>  - after merge with 8366363.
>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>  - 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 217:

> 215:   }
> 216: 
> 217:   VirtualMemoryRegion(address addr, size_t size, const NativeCallStack& stack, bool committed) :

Correct me if I'm wrong but is this `committed` only ever true? And then we use the presence of this constructor parameter to decide whether we are creating a committed or a reserved region?

If so, at the very least we should assert that committed is true. But I think it would be nicer to make the constructor private and make some static factory methods akin to `VirtualMemoryRegion::committed` and `VirtualMemoryRegion::reserved`.

src/hotspot/share/nmt/virtualMemoryTracker.hpp line 271:

> 269:   inline const NativeCallStack* committed_call_stack() const         { return &_committed_stack; }
> 270: 
> 271:   bool is_valid() const { return base() != nullptr && size() != 0;}

The old structures had the base address and size by default initialised to 1. I think the new "invalid" values of 0 and 0 are more ergonomic, but I'm wondering, what's the reason we used 1 originally?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2546002237
PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2545990569

From aboldtch at openjdk.org  Thu Nov 20 13:14:19 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 13:14:19 GMT
Subject: RFR: 8372242: Gtest LogTagSet.defaults should run in OTHER VM [v2]
In-Reply-To: <bw7-kyaN8SOAG0DJc6iO9gt29Qjm4jDtu3FCkCCzEOM=.b6dda0c2-8939-4342-b208-b810e51cfa28@github.com>
References: <bw7-kyaN8SOAG0DJc6iO9gt29Qjm4jDtu3FCkCCzEOM=.b6dda0c2-8939-4342-b208-b810e51cfa28@github.com>
Message-ID: <pM6l6L80xmTBTDiB5kvqrRG0VOkTW3Fg8ehj0Opd97s=.09c7605e-f8f0-42e7-8335-cf3fd9a7de76@github.com>

> LogTagSet.defaults checks some of the default `LogTagSet` properties and assumes a fresh VM. This test will fail if the other `LogTagSet` have run first.
> 
> As this test is ment to test the defaults of the LogTagSet, it should be ran in an OTHER VM. 
> 
> We might still have problems if logging flags are given to the GTestLauncher. But all our jtreg GTest runners are `@requires vm.flagless`, so this should only occur when running very custom test invocations.

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 two commits:

 - Merge branch 'JDK-8372241' into JDK-8372242
 - Gtest LogTagSet.defaults should run in OTHER VM

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

Changes: https://git.openjdk.org/jdk/pull/28411/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28411&range=01
  Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28411/head:pull/28411

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

From aboldtch at openjdk.org  Thu Nov 20 13:16:28 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 13:16:28 GMT
Subject: RFR: 8372246: LogOutputList gtests should not use LogConfiguration
 LogOutputs [v2]
In-Reply-To: <wopRTmbbbEEBIITHdSw_Ocdg6qAe2Jz3sRaX8LVRYEk=.fbea1965-d674-4ee5-ae3b-780f6de9fd82@github.com>
References: <wopRTmbbbEEBIITHdSw_Ocdg6qAe2Jz3sRaX8LVRYEk=.fbea1965-d674-4ee5-ae3b-780f6de9fd82@github.com>
Message-ID: <JtsEaDR-XIuWo6_kb97oPWdbZznQPA90iKodFrC2jnk=.6b24af4c-12d1-4caa-971d-a93e3eb43aa6@github.com>

> A handful of `LogOutputList` tests uses `LogConfiguration::Std[out|err]Log` LogOutputs in its tests.
> However these are not setup unless we run the tests in VM mode.
> 
> I suggest we add some dummy `LogOutputs` for `StdoutLog` and `StderrLog` which these tests can use, so they are not depending being a VM test.

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 two commits:

 - Merge branch 'JDK-8372241' into JDK-8372246
 - LogOutputList gtests should not use LogConfiguration LogOutputs

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

Changes: https://git.openjdk.org/jdk/pull/28416/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28416&range=01
  Stats: 27 lines in 2 files changed: 10 ins; 4 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/28416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28416/head:pull/28416

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

From aboldtch at openjdk.org  Thu Nov 20 13:17:37 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 13:17:37 GMT
Subject: RFR: 8372247: OSX: Semaphore.trywait requires os::Bsd::clock_init
 [v2]
In-Reply-To: <eVakkuHWTHGDS0VJIu85hHuVfhNppo37w0HOwFV0tXs=.5c5d33eb-a525-44f2-9f45-d360ca226377@github.com>
References: <eVakkuHWTHGDS0VJIu85hHuVfhNppo37w0HOwFV0tXs=.5c5d33eb-a525-44f2-9f45-d360ca226377@github.com>
Message-ID: <9MlZLzpYpGYJIyCY3nFJedkS5QYAdQeomGjYe_GB8HE=.63297eda-e56d-40c2-a96e-5ec409404809@github.com>

> The OSX implementation of the Semaphore requires `os::javaTimeNanos` which requires that we have initiated the clocks via `os::Bsd::clock_init()`. Or we will get an integer division by zero when performing a trywait.
> 
> I propose that we let this test setup `os::Bsd::clock_init()` rather than being forced to run in VM.
> 
> An alternative would be to simply run this test in VM. Making the dependency more clear. Or only use VM for `__APPLE__`.

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 two commits:

 - Merge branch 'JDK-8372241' into JDK-8372247
 - OSX: Semaphore.trywait requires os::Bsd::clock_init

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

Changes: https://git.openjdk.org/jdk/pull/28417/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28417&range=01
  Stats: 10 lines in 2 files changed: 8 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28417.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28417/head:pull/28417

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

From aboldtch at openjdk.org  Thu Nov 20 13:17:42 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 20 Nov 2025 13:17:42 GMT
Subject: RFR: 8372243: ZGC: ZForwardingTest.find_every_other is mistaken
 for a other VM gtest [v2]
In-Reply-To: <sUhmeUbJ-nFVj36tBsWQHp9XxnkmlnKr1jirU4kfFrY=.a97e563e-6ad7-467e-8ef0-00f3d2fdb291@github.com>
References: <sUhmeUbJ-nFVj36tBsWQHp9XxnkmlnKr1jirU4kfFrY=.a97e563e-6ad7-467e-8ef0-00f3d2fdb291@github.com>
Message-ID: <_kNxEF0kLy1KrWYN-vxv8MNnKTvB175J1HyFuX5ZIlE=.90eaa9a0-56f6-48e8-a0dc-423d236d9eef@github.com>

> The current implementation of our GTest runner identifies the category of test by the suffix it adds.
> This is either `_vm`, `_other_vm` or `_vm_assert`. This is problematic for `ZForwardingTest.find_every_other` which is a VM test and ends up with the final name `ZForwardingTest.find_every_other_vm` and is mistaken for an other VM test in the filters, but is run as a VM test. Currently `ZForwardingTest.find_every_other` if another VM test has been ran first.
> 
> I propose we enhance our GTest category naming to make this thing impossible by:
> 1. Change `_vm`, `_other_vm` and `_vm_assert` to `__vm`, `__other_vm` and `__vm_assert`
> 2. Fail to compile tests which end in `_`, `__vm`, `__other_vm` or `__vm_assert`
> 
> Note that this patch uses an undecided hotspot feature in the gtest launcher `std::string_view`.
> It would be very unfortunate to not be able to use this feature, as without it (or a similar construction) performing static checking of strings and sub-strings is rather cumbersome.

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 two commits:

 - Merge branch 'JDK-8372241' into JDK-8372243
 - ZGC: ZForwardingTest.find_every_other is mistaken for a other VM gtest

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

Changes: https://git.openjdk.org/jdk/pull/28412/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28412&range=01
  Stats: 42 lines in 7 files changed: 18 ins; 7 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28412.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28412/head:pull/28412

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

From aartemov at openjdk.org  Thu Nov 20 15:17:28 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 15:17:28 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v16]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <nivfjqo4sMH29N_I4lddu1-ucNl9Z5BZPE50w3-A4Nk=.a772b055-25c5-4df5-a0bd-5fe93f48732f@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Refactoring.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/9356cd9f..301999cb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=14-15

  Stats: 74 lines in 6 files changed: 41 ins; 28 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27040/head:pull/27040

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

From aartemov at openjdk.org  Thu Nov 20 15:31:10 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 15:31:10 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
Message-ID: <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>

> Hi, please consider the following changes:
> 
> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
> 
> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> This can happen in two places where the successor could be suspended: 
> 1:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
> 
> 2:
> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
> 
> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
> 
> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
> 
> Tests are added for both scenarios. 
> 
> Tested in tiers 1 - 7.

Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:

  8366659: Fixed whitespace error.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27040/files
  - new: https://git.openjdk.org/jdk/pull/27040/files/301999cb..322fc0e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27040&range=15-16

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

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

From aartemov at openjdk.org  Thu Nov 20 15:31:11 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Thu, 20 Nov 2025 15:31:11 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
 <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
Message-ID: <_-5I-bhvp2aJb6ki9uBaAjYYRBi6EKQVrD4QQHj4Mv4=.8f3da38f-5397-4c86-ad1d-c9bd65b677ed@github.com>

On Thu, 20 Nov 2025 05:38:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the `monitor_waited` event would be posted whilst the thread is still suspended. To be clear(er) in the old code we would do:
> 
> ```
> wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor
> ```
> 
> whereas the new code, if we kept the placement of the event, would do
> 
> ```
> wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor
> ```
> 
> and what the proposed code actually does is
> 
> ```
> wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor -> post monitor_waited 
> ```
> 
> Given the lack of specificity in the JVM TI spec around these different events I think any assumptions in a TCK test could be challenged, but it would still be a change in behaviour.

@dholmes-ora I have done a bit of refactoring and introduced a private method `post_waited_event()`, which we can call in different places depending on the scenario. 

For instance, for the timed-out case, the sequence of events is now unchanged, i.e.:
`wait -> waited -> contended enter -> contended entered`

For notified case, using your extended notation, it is now behaving like this: 
`wait  -> reenter monitor -> suspend if needed and drop monitor -> resumed -> post monitor_waited -> reenter monitor`

I think this is what we eventually want. @sspitsyn could you confirm/refute that it does not change thread state bits? 
The JVMTI tests pass, the extended testing is in progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3558649501

From asmehra at openjdk.org  Thu Nov 20 15:57:34 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Thu, 20 Nov 2025 15:57:34 GMT
Subject: RFR: 8372253: Improve logging to show why a class was excluded
 form AOT Cache
In-Reply-To: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
References: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
Message-ID: <ByFlfThs-O8agKjkVoC7b9R8DQPOM-_ZLexMTpN5f_w=.f59a79b2-0ce5-4744-86cf-01e0f0d37447@github.com>

On Thu, 20 Nov 2025 09:20:11 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

> Fixes: https://bugs.openjdk.org/browse/JDK-8372253
> 
> When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
> [warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification
> 
> 
> This PR improves the log message by adding the cause of this failure:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod

Marked as reviewed by asmehra (Committer).

lgtm

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

PR Review: https://git.openjdk.org/jdk/pull/28413#pullrequestreview-3488609372
PR Comment: https://git.openjdk.org/jdk/pull/28413#issuecomment-3558797125

From macarte at openjdk.org  Thu Nov 20 16:00:52 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 16:00:52 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v4]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <mnL_C62m-qyvqY_juhpr4DJxNPemgkamteRqXuNViQk=.7f45acbb-10c5-4c6b-a1d4-6beadb977ec9@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into JDK-8370203
 - Updates based on feedback.  Method name changes; clearer output; commnets on implemenation; remove redundant logic
 - Document use of DiagnosticCommand
 - Adding test to validate using DiagnosticCommand MBean to invoke AOT.end_recording
 - Switched line endings to unix style LF
 - Removed timing functionality as it's not needed yet
 - Sort headers correctly
 - 8370203 - Adding JCmd AOT.end_recording

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

Changes: https://git.openjdk.org/jdk/pull/27965/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=03
  Stats: 288 lines in 6 files changed: 288 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965

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

From macarte at openjdk.org  Thu Nov 20 16:22:29 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 16:22:29 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - Error! Not a recording run
> - Error! Not recording
> - Recording ended successfully
> - Error! Failed to end recording
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully
> - Error! Not recording
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
 - Corrected placement of assert and logic test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/0ac132b6..f1f5d77d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=03-04

  Stats: 11 lines in 1 file changed: 1 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965

PR: https://git.openjdk.org/jdk/pull/27965

From macarte at openjdk.org  Thu Nov 20 16:33:41 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 16:33:41 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v3]
In-Reply-To: <RSjjzwKMG4-YqC9lcW07Je0dchm3G2efkD8sGpmkQiU=.ace856e5-2c8b-43c0-a5a0-aeaab317a679@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <hVb946CJ5KooBE9c6ZeqTHzCGxnPgU8YCii1cz_khVc=.5d37d9cf-329a-44aa-ae20-30171c764015@github.com>
 <RSjjzwKMG4-YqC9lcW07Je0dchm3G2efkD8sGpmkQiU=.ace856e5-2c8b-43c0-a5a0-aeaab317a679@github.com>
Message-ID: <RZvDQjuYHIsu83R9vRb1g1huEIqslNi-OrQec2RdfZY=.ce651849-5ff9-465b-8fe5-99f193546f4f@github.com>

On Fri, 14 Nov 2025 12:58:33 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Document use of DiagnosticCommand
>
> src/hotspot/share/services/diagnosticCommand.cpp line 991:
> 
>> 989: }
>> 990: 
>> 991: #if INCLUDE_CDS
> 
> A simple style nit-pick:  Error!
> The JVM doesn't really dramatize problems like that.  It tells you there was an error, and calmly describes the problem after a colon. "Error: " 8-)
> 
> (There are some "Error!" exclamations in java.xml and one has got into jdk.jfr, but they are unusual.)
> 
> You can tell me that nit-picking is NOT hyphenated if you like.

Thank you, we've removed the "!" from "Error: Failed to end recording" and also removed the "Error! " prefix from the other outputs that weren't internal errors

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2546768475

From coleenp at openjdk.org  Thu Nov 20 17:14:42 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 20 Nov 2025 17:14:42 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null
Message-ID: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>

The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry (error field). Multiple threads were adding duplicate entries for nest_host_errors in the case where resolution failed and where there was already a nest host error in the ResolultionErrorEntry.  Add a null check and an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index.
Tested with submitted reproducer and tier1-4.

-------------

Commit messages:
 - 8365526: Crash with null Symbol passed to SystemDictionary::resolve_or_null

Changes: https://git.openjdk.org/jdk/pull/28438/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365526
  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28438/head:pull/28438

PR: https://git.openjdk.org/jdk/pull/28438

From kvn at openjdk.org  Thu Nov 20 19:49:03 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Nov 2025 19:49:03 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <74lT8czpnsYK5yL46LqHFZFq7HCaJRtOb_lplgxkaPc=.8305a9e3-8125-4922-b7b5-3c112452516f@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

Looks like you merged your other Mbeans PR changes into this. Which is wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3559758757

From iklam at openjdk.org  Thu Nov 20 20:36:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 20 Nov 2025 20:36:56 GMT
Subject: RFR: 8372253: Improve logging to show why a class was excluded
 form AOT Cache
In-Reply-To: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
References: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
Message-ID: <OaHN6oKIAe7AVdlrIA9lehW6mUec8bSvlrN2l_QCKeI=.93ffcdd0-2b62-4487-b894-ffd1f893a3fa@github.com>

On Thu, 20 Nov 2025 09:20:11 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

> Fixes: https://bugs.openjdk.org/browse/JDK-8372253
> 
> When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
> [warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification
> 
> 
> This PR improves the log message by adding the cause of this failure:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod

Marked as reviewed by iklam (Reviewer).

Thanks for making the changes. I have a written a test case.


class ExclusionTest {
    public void main() {
        System.out.println("I am not calling getFoo()");
    }

    // The verification of this method adds a verification constraint:
    //     Bar must be a subclass of Foo
    //
    // Note that the verification of this class only loads Bar and Foo
    // to check that Bar is a subclass of Foo. It does not cause
    // Bar and Foo to be immediately verified.
    //
    // Bar and Foo are verified only when the app uses them, or
    // in the case of AOT training, they are verified after the app
    // has exited but before we write the AOT config file.
    Foo getFoo() {
        return new Bar();
    }
}

// Foo is verified at the end of the training run in AOTMetaspace::link_all_loaded_classes().
// This is AFTER the app has exited.
class Foo {}

// Bar is also verified at end of the training run. The verification will fail
// because Baz cannot be loaded,
//
// As a result, Bar is excluded from the AOT config.
// ExclusionTest is also excluded, because its verification depended on Bar.
class Bar extends Foo {
    Bar getBar() {
        return new Baz(); // Bar cannot be verified if Baz class cannot be loaded,
    }
}

// Do NOT put this class in the classpath
class Baz extends Bar {}


With the new log added by this PR, we can now understand why `Bar` and `ExclusionTest` are excluded:


$ rm -rf tmpclasses
$ mkdir -p tmpclasses
$ javac -d tmpclasses ExclusionTest.java
$ rm tmpclasses/Baz.class
$ jar cvf ExclusionTest.jar -C tmpclasses .

$ java -XX:AOTMode=record -XX:AOTConfiguration=test.aotconf \
    -cp ExclusionTest.jar ExclusionTest | egrep '(Skip)|(Preload)'
[0.125s][warning][aot] Preload Warning: Verification failed for Bar because a 
     java.lang.NoClassDefFoundError was thrown: Baz
[...]
[0.242s][warning][aot] Skipping Bar: Failed verification
[0.242s][info   ][aot] Skipping ExclusionTest: verification constraint Bar is excluded

-------------

PR Review: https://git.openjdk.org/jdk/pull/28413#pullrequestreview-3489831233
PR Comment: https://git.openjdk.org/jdk/pull/28413#issuecomment-3559947611

From dholmes at openjdk.org  Thu Nov 20 22:08:40 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 20 Nov 2025 22:08:40 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
Message-ID: <atjB0q71hgsP6wOWok55Tn_86RnKB19LPan8BAUiDVE=.61d7ea56-0481-4678-bf3c-1a3793bc6a4b@github.com>

On Thu, 20 Nov 2025 08:27:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better assert messages

LGTM. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28317#pullrequestreview-3490151681

From macarte at openjdk.org  Thu Nov 20 22:11:20 2025
From: macarte at openjdk.org (Mat Carter)
Date: Thu, 20 Nov 2025 22:11:20 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <74lT8czpnsYK5yL46LqHFZFq7HCaJRtOb_lplgxkaPc=.8305a9e3-8125-4922-b7b5-3c112452516f@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <74lT8czpnsYK5yL46LqHFZFq7HCaJRtOb_lplgxkaPc=.8305a9e3-8125-4922-b7b5-3c112452516f@github.com>
Message-ID: <yV7NUI80tWOtl07DxWy3DFWw5_GKDrP3rFK-TGE0_VI=.2b637405-3e31-497c-b428-6a727bfbf765@github.com>

On Thu, 20 Nov 2025 19:45:22 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Looks like you merged your other Mbeans PR changes into this. Which is wrong.

I resolved a conflict with Ioi's change from yesterday, but I don't see any HotSpotAOTCacheMXBean code.  Is there a specific commit you can reference?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560266811

From kvn at openjdk.org  Thu Nov 20 23:31:19 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Nov 2025 23:31:19 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <YfWWCMGrAgCIqNfAaSsesVDCDjzUV3BOhXRlbCoaKWc=.6f89804a-208d-4a17-8e89-39aac7642597@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

I was confused by this Github warning "This pull request contains merges that bring in commits not present in the target repository. "

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560622271

From kvn at openjdk.org  Thu Nov 20 23:43:58 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 20 Nov 2025 23:43:58 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <xxdSCtLr_SUIqtB7NG6dGHOql2pLfUMPPcXHeClNACs=.42b14cfa-a6ae-44e0-85fa-8d99d85e1c04@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

Looks good now.

`KAT9180` is not related to your changes. It is new test added today.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3490547075
PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560659510

From sspitsyn at openjdk.org  Thu Nov 20 23:58:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Nov 2025 23:58:41 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
 <JyynL8mRjCUAVZQVOJOH4sJe7ocwqRHeS30EztqxzUg=.81a73714-728a-43fc-a993-5d9cc9d47f25@github.com>
Message-ID: <IDJU9QFhmhYcFahIxD8FvcW9UZtVVOrAsFmBHe_HgGs=.115b6b32-cb21-4d51-84e3-ad1199181012@github.com>

On Thu, 20 Nov 2025 05:38:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Changes requested by lmesnik (Reviewer).
>
> @lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern. That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself. Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.
> 
> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the `monitor_waited` event would be posted whilst the thread is still suspended. To be clear(er) in the old code we would do:
> 
> wait -> suspend if needed -> resumed -> post monitor_waited -> renter monitor
> 
> whereas the new code, if we kept the placement of the event,  would do
> 
> wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor
> 
> and what the proposed code actually does is
> 
> wait -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor -> post monitor_waited 
> 
> 
> Given the lack of specificity in the JVM TI spec around these different events I think any assumptions in a TCK test could be challenged, but it would still be a change in behaviour.

@dholmes-ora David, thank you for your input!

> @dholmes-ora I have done a bit of refactoring and introduced a private method post_waited_event(), which we can call in different places depending on the scenario.

I like the refactoring.

> For instance, for the timed-out case, the sequence of events is now unchanged, i.e.:
> `wait -> waited -> contended enter -> contended entered`
> 
> For the notified case, using your extended notation, it is now behaving like this:
> `wait  -> reenter monitor -> suspend if needed and drop monitor -> resumed -> post monitor_waited -> reenter monitor`

My understanding is that we need both timed-out and notified cases to do the same as David suggested above:
  `wait -> post monitor_waited -> reenter monitor -> suspend if needed and drop monitor -> resumed -> reenter monitor`
It would give us two advantages:
 - timed-out and notified cases are unified
 - avoid incompatibility risk, e.g.:
   - no new combinations of JVMTI thread state bits are introduced
   - the object monitor events order is kept same as was before (is it true?)

Is there a problem to make it unified?

> I think this is what we eventually want. @sspitsyn could you confirm/refute that it does not change thread state bits?

As I see, this still introduces new combinations of thread state bits for the notified case.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3560695036

From sspitsyn at openjdk.org  Fri Nov 21 00:25:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 00:25:04 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v13]
In-Reply-To: <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <gXTvJqiDSyel3ApkA5DghPeFX3OotVngolKH46bO7MI=.306beae5-96b9-46a6-abd4-c084f576e262@github.com>
 <OfHHc-ba5knbMw0IECkLBUFZ6xjSWY6LnuYUm1Y4beU=.140747fd-cb2f-4afd-a1fc-6fbbc333e232@github.com>
Message-ID: <uoo3qc9UX9DOhJD8Lm_KhBdzbvywX1Cl-MMl4jKI688=.92f650ef-9a20-4667-a569-2bcf22b2ef3f@github.com>

On Wed, 19 Nov 2025 22:55:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Refactored tests.
>
> Changes requested by lmesnik (Reviewer).

> @lmesnik are the JVMTI thread state transitions performed in the event posting code? If so the different order, and thus different states, would be a concern.

Yes, JVMTI event posting code performs thread state transitions. But I was talking about the JVMTI thread state bits specified here: https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#GetThreadState

> That said we have noticed that only the timeout case seems to operate in a way that the monitor reentry can post contended_enter and contended_entered events, which seems very odd in itself.

Right. We have this oddity.

> Though I will also note that the way the suspension code drops and then re-acquires the monitor, any contended_enter* events could get posted multiple times which would also be surprising.

Right. There have to be some ways to fix it. Most likely we already have a bug against this issue.


> Maintaining the event order is problematic as, with the fix to the deadlock issue, we only allow suspension during reentry, and that would mean the monitor_waited event would be posted whilst the thread is still suspended.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3560750605

From kvn at openjdk.org  Fri Nov 21 00:50:23 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 21 Nov 2025 00:50:23 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <xxdSCtLr_SUIqtB7NG6dGHOql2pLfUMPPcXHeClNACs=.42b14cfa-a6ae-44e0-85fa-8d99d85e1c04@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <xxdSCtLr_SUIqtB7NG6dGHOql2pLfUMPPcXHeClNACs=.42b14cfa-a6ae-44e0-85fa-8d99d85e1c04@github.com>
Message-ID: <0sF4opLAcZ44ZcCa2Kj5pn88ytM7OasvOMHs3LDvwY8=.839b8cf8-c63d-40f1-a660-a938e0d919e0@github.com>

On Thu, 20 Nov 2025 23:40:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `KAT9180` is not related to your changes. It is new test added today.

I mean `KAT9180` test failure in GHA is not related to your changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3560825050

From lmesnik at openjdk.org  Fri Nov 21 00:59:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 21 Nov 2025 00:59:52 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
Message-ID: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>

On Thu, 20 Nov 2025 16:22:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>  - Corrected placement of assert and logic test

Changes requested by lmesnik (Reviewer).

src/hotspot/share/cds/aotMetaspace.cpp line 1062:

> 1060: bool AOTMetaspace::preimage_static_archive_dumped() {
> 1061:   assert(CDSConfig::is_dumping_preimage_static_archive(), "Required");
> 1062:   return _preimage_static_archive_dumped == 1;

Should it be  AtomicAccess::load(&_preimage_static_archive_dumped) here?

test/hotspot/jtreg/runtime/cds/appcds/aotCache/DiagnosticCommandMBeanTest.java line 98:

> 96:                     out.shouldContain("Failed to stop recording");
> 97:                 }
> 98:                 out.shouldNotContain("IOException occurred!");

The 'IOException occurred!' is never printed. While there are a lot of other exception print and not checked.

Also makes sense to check exit status.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 31:

> 29:  * @summary Sanity test for Jcmd AOT.end_recording command
> 30:  * @library /test/lib
> 31:  * @build JcmdAOTEndRecordingTest

No need to build test explicitly, jtreg does it by itself.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 57:

> 55:             try {
> 56:                 OutputAnalyzer output = ProcessTools.executeProcess(jcmd.getCommand());
> 57:                 output.shouldContain("AOT.end_recording is unsupported");

A little bit confused.  The check doesn't match test description.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3490649441
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548182449
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548168094
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548140140
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2548148536

From dholmes at openjdk.org  Fri Nov 21 02:37:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Nov 2025 02:37:01 GMT
Subject: RFR: 8372247: OSX: Semaphore.trywait requires os::Bsd::clock_init
 [v2]
In-Reply-To: <9MlZLzpYpGYJIyCY3nFJedkS5QYAdQeomGjYe_GB8HE=.63297eda-e56d-40c2-a96e-5ec409404809@github.com>
References: <eVakkuHWTHGDS0VJIu85hHuVfhNppo37w0HOwFV0tXs=.5c5d33eb-a525-44f2-9f45-d360ca226377@github.com>
 <9MlZLzpYpGYJIyCY3nFJedkS5QYAdQeomGjYe_GB8HE=.63297eda-e56d-40c2-a96e-5ec409404809@github.com>
Message-ID: <ejNw60avULNN033U7xopw1VkFmAQSqIV2Hw1X43tg6Y=.be6305fd-3f06-4285-8a94-5be362a2205d@github.com>

On Thu, 20 Nov 2025 13:17:37 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> The OSX implementation of the Semaphore requires `os::javaTimeNanos` which requires that we have initiated the clocks via `os::Bsd::clock_init()`. Or we will get an integer division by zero when performing a trywait.
>> 
>> I propose that we let this test setup `os::Bsd::clock_init()` rather than being forced to run in VM.
>> 
>> An alternative would be to simply run this test in VM. Making the dependency more clear. Or only use VM for `__APPLE__`.
>
> 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 two commits:
> 
>  - Merge branch 'JDK-8372241' into JDK-8372247
>  - OSX: Semaphore.trywait requires os::Bsd::clock_init

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28417#pullrequestreview-3490924946

From vpetko at openjdk.org  Fri Nov 21 05:37:12 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 21 Nov 2025 05:37:12 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
Message-ID: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>

This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.

Reverted changes to:
 -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries

Testing (in Ubuntu 26.04 i386 chroot):

$ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
...
$ make images
Building target 'images' in configuration 'linux-x86-zero-release'
Warning: No SCM configuration present and no .src-rev
Updating images/sec-bin.zip
Finished building target 'images' in configuration 'linux-x86-zero-release'
$

-------------

Commit messages:
 - fix: partially revert jdk-8351148 to restore zero build on 32 bit platforms

Changes: https://git.openjdk.org/jdk/pull/28406/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28406&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370978
  Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28406.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28406/head:pull/28406

PR: https://git.openjdk.org/jdk/pull/28406

From sspitsyn at openjdk.org  Fri Nov 21 07:29:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 07:29:44 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
Message-ID: <0Q_8lJFi3PoCAyh_JkV0qnTox-2Z8qajHHUQHUjyJ7k=.ede07dbf-498e-4ff4-981a-7cd636d1e9a8@github.com>

On Thu, 20 Nov 2025 15:31:10 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Fixed whitespace error.

I'm reading this bug description in JBS:

> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible in two cases:
> 
> 1) The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and then exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
> 
> 2) The race between suspension and retry: the thread could reacquire the OM and complete the wait() code in full, but then on return to Java it will be suspended while holding the OM.

I'm not sure the described scenarios above are real deadlocks. The debugger has to be careful with threads suspension and can behave differently. For instance, it can suspend all threads, so no thread can progress with entering OM's. We do not consider it to be a deadlock, right?
In a case just a single thread is being suspended by the debugger, other threads can depend on the suspended thread. But we do not consider it to be a deadlock. It is because everything should come to normal after the debugger resumes the suspended thread.
So, could you, please, explain a little bit more on the deadlocks above? How the described in the bug scenarios are different from just listed ones? Do I miss anything?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3561786718

From duke at openjdk.org  Fri Nov 21 07:52:21 2025
From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac)
Date: Fri, 21 Nov 2025 07:52:21 GMT
Subject: RFR: 8372253: Improve logging to show why a class was excluded
 form AOT Cache
In-Reply-To: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
References: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
Message-ID: <n5CO41TGaBneUyeuQLR5l_PcAEYo2E2IfyyEkNG3Oow=.ff0edf3c-fb90-4ef0-90e0-858635a72cc9@github.com>

On Thu, 20 Nov 2025 09:20:11 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

> Fixes: https://bugs.openjdk.org/browse/JDK-8372253
> 
> When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
> [warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification
> 
> 
> This PR improves the log message by adding the cause of this failure:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod

The PR title is "8372253: Improve logging to show why a class was excluded form AOT Cache".
Dunno if it's important to fix a typo there, but if it is then "form" should be "from".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28413#issuecomment-3561839386

From sspitsyn at openjdk.org  Fri Nov 21 08:00:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 08:00:32 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
Message-ID: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>

On Thu, 20 Nov 2025 15:31:10 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

>> Hi, please consider the following changes:
>> 
>> If suspension is allowed when a thread is re-entering an object monitor (OM), then a deadlock is possible:
>> 
>> The waiting thread is made to be a successor and is unparked. Upon a suspension request, the thread will suspend itself whilst clearing the successor. The OM will be left unlocked (not grabbed by any thread), while the other threads are parked until a thread grabs the OM and the exits it. The suspended thread is on the entry-list and can be selected as a successor again. None of other threads can be woken up to grab the OM until the suspended thread has been resumed and successfully releases the OM.
>> 
>> This can happen in two places where the successor could be suspended: 
>> 1:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1897
>> 
>> 2:
>> https://github.com/openjdk/jdk/blob/6322aaba63b235cb6c73d23a932210af318404ec/src/hotspot/share/runtime/objectMonitor.cpp#L1149
>> 
>> The issues are addressed by not allowing suspension in case 1, and by handling the suspension request at a later stage, after the thread has grabbed the OM in `reenter_internal()` in case 2. In case of a suspension request, the thread exits the OM and enters it again once resumed. 
>> 
>> The JVMTI `waited` event posting (2nd one) is postponed until the suspended thread is resumed and has entered the OM again.  The `enter` to the OM (in case `ExitOnSuspend` did exit) is done without posting any events.
>> 
>> Tests are added for both scenarios. 
>> 
>> Tested in tiers 1 - 7.
>
> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8366659: Fixed whitespace error.

I'm looking at the  two new tests scenarios. They look non-real and very artificial because the application plays a role of the debugger at the same time and constructs the artificial deadlocks. The threads sync on an application lock, one of them suspends and another resumes the target thread. These deadlocks are impossible to have with any normal debugger which is decoupled from application it is debugging.
Sorry for saying it but it feels like there is no sense to fix this artificial issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3561858635

From mbaesken at openjdk.org  Fri Nov 21 08:12:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Nov 2025 08:12:55 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
Message-ID: <naTzek-VOr2EfA16_y4KPrae7FNmSA6vQbO91qaYs8E=.d27d9372-045d-4d62-9986-63dea3baf116@github.com>

On Thu, 20 Nov 2025 08:27:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better assert messages

Hi David and Alan, thanks for the reviews !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28317#issuecomment-3561894485

From duke at openjdk.org  Fri Nov 21 08:22:15 2025
From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=)
Date: Fri, 21 Nov 2025 08:22:15 GMT
Subject: RFR: 8372253: Improve logging to show why a class was excluded
 from AOT Cache
In-Reply-To: <OaHN6oKIAe7AVdlrIA9lehW6mUec8bSvlrN2l_QCKeI=.93ffcdd0-2b62-4487-b894-ffd1f893a3fa@github.com>
References: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
 <OaHN6oKIAe7AVdlrIA9lehW6mUec8bSvlrN2l_QCKeI=.93ffcdd0-2b62-4487-b894-ffd1f893a3fa@github.com>
Message-ID: <zXKBZZYALur69vkGl3nMBqkKqnbGw1G-zQH5iwtnVdc=.37c81dc7-70d1-411c-96c3-defc2bed63b3@github.com>

On Thu, 20 Nov 2025 20:33:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Fixes: https://bugs.openjdk.org/browse/JDK-8372253
>> 
>> When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:
>> 
>> 
>> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
>> [warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification
>> 
>> 
>> This PR improves the log message by adding the cause of this failure:
>> 
>> 
>> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod
>
> Thanks for making the changes. I have a written a test case.
> 
> 
> class ExclusionTest {
>     public void main() {
>         System.out.println("I am not calling getFoo()");
>     }
> 
>     // The verification of this method adds a verification constraint:
>     //     Bar must be a subclass of Foo
>     //
>     // Note that the verification of this class only loads Bar and Foo
>     // to check that Bar is a subclass of Foo. It does not cause
>     // Bar and Foo to be immediately verified.
>     //
>     // Bar and Foo are verified only when the app uses them, or
>     // in the case of AOT training, they are verified after the app
>     // has exited but before we write the AOT config file.
>     Foo getFoo() {
>         return new Bar();
>     }
> }
> 
> // Foo is verified at the end of the training run in AOTMetaspace::link_all_loaded_classes().
> // This is AFTER the app has exited.
> class Foo {}
> 
> // Bar is also verified at end of the training run. The verification will fail
> // because Baz cannot be loaded,
> //
> // As a result, Bar is excluded from the AOT config.
> // ExclusionTest is also excluded, because its verification depended on Bar.
> class Bar extends Foo {
>     Bar getBar() {
>         return new Baz(); // Bar cannot be verified if Baz class cannot be loaded,
>     }
> }
> 
> // Do NOT put this class in the classpath
> class Baz extends Bar {}
> 
> 
> With the new log added by this PR, we can now understand why `Bar` and `ExclusionTest` are excluded:
> 
> 
> $ rm -rf tmpclasses
> $ mkdir -p tmpclasses
> $ javac -d tmpclasses ExclusionTest.java
> $ rm tmpclasses/Baz.class
> $ jar cvf ExclusionTest.jar -C tmpclasses .
> 
> $ java -XX:AOTMode=record -XX:AOTConfiguration=test.aotconf \
>     -cp ExclusionTest.jar ExclusionTest | egrep '(Skip)|(Preload)'
> [0.125s][warning][aot] Preload Warning: Verification failed for Bar because a 
>      java.lang.NoClassDefFoundError was thrown: Baz
> [...]
> [0.242s][warning][aot] Skipping Bar: Failed verification
> [0.242s][info   ][aot] Skipping ExclusionTest: verification constraint Bar is excluded

@iklam should we add the test case to this PR? Otherwise, feel free to /sponsor me

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28413#issuecomment-3561911585

From duke at openjdk.org  Fri Nov 21 08:22:17 2025
From: duke at openjdk.org (duke)
Date: Fri, 21 Nov 2025 08:22:17 GMT
Subject: RFR: 8372253: Improve logging to show why a class was excluded
 from AOT Cache
In-Reply-To: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
References: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
Message-ID: <l29yzEhPw933S8Nyb4WrRCX6i1smX-mt66vbz4sMTig=.40e412d5-55a5-4093-9f34-6244861d3807@github.com>

On Thu, 20 Nov 2025 09:20:11 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

> Fixes: https://bugs.openjdk.org/browse/JDK-8372253
> 
> When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
> [warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification
> 
> 
> This PR improves the log message by adding the cause of this failure:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod

@Delawen 
Your change (at version f6a4af8c66a9e0b70141f19b1ec9ed85179fb12b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28413#issuecomment-3561924827

From stefank at openjdk.org  Fri Nov 21 08:23:55 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 21 Nov 2025 08:23:55 GMT
Subject: RFR: 8371990: Remove two second delayed OOME after GC shutdown
 [v4]
In-Reply-To: <shP2-MDXK_C_uOidBkPOXGOhul0ZMoWeFNj-smLcuPo=.a6e8de5a-4cf7-4360-98d2-2eb82d23592e@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
 <shP2-MDXK_C_uOidBkPOXGOhul0ZMoWeFNj-smLcuPo=.a6e8de5a-4cf7-4360-98d2-2eb82d23592e@github.com>
Message-ID: <XUb6P8xPRJL3tZbQ9uhSrJbk-B3luFAeQYovClg9IjE=.4722b564-7196-4211-a923-e8480f787ced@github.com>

On Wed, 19 Nov 2025 07:21:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
>> 
>> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
>> 
>> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
>> 
>> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
>> 
>> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
>> 
>> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
>> 
>> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
>> 
>> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
>> 
>> There are some G1 specific details to look at:
>> 
>> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
>> 
>> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
>> 
>> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to d...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thank you all for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28349#issuecomment-3561928695

From stefank at openjdk.org  Fri Nov 21 08:23:56 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 21 Nov 2025 08:23:56 GMT
Subject: Integrated: 8371990: Remove two second delayed OOME after GC shutdown
In-Reply-To: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
References: <GSBm_pNIXZkA2EVxJJtc9lass4B2tyUYAPz-j7YTXtk=.a015b552-97ae-46bb-b04e-3ef2a0cba531@github.com>
Message-ID: <1rrKNoaXmN5a5LLfhpZS8ioPMoCXZJzcxSPLqZ8gTIo=.1e2e8f3f-2103-4b90-8771-530ad63e5bb5@github.com>

On Mon, 17 Nov 2025 13:15:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> In [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865) the shutdown code was tweaked so that allocating code would try to block for two seconds and if the JVM didn't shut down within that time, an OOME was thrown from the allocating thread.
> 
> One of the reason why this code was introduced was to deal with shutdown problem where the thread that were shutting down the JVM would first initiate the shutdown of the GC and *after* that the thread would call the JVMTI shutdown events and callbacks. The JVMTI callbacks could call arbitrary Java code that could try to allocate memory, and if the heap was filled up, it would have to wait for a GC to do its thing and hand back memory. But the GC had initiated its termination protocol and could be unresponsive to that request, which in term would lead to hanging JVM process.
> 
> The problem described above was finally fixed with [JDK-8367902](https://bugs.openjdk.org/browse/JDK-8367902).
> 
> So, I propose that we get rid of the workaround put into place with [JDK-8366865](https://bugs.openjdk.org/browse/JDK-8366865).
> 
> The proposed patch restructures the GC shutdown a little bit. The idea is all threads that want to schedule a GC VM Operation already take the Heap_lock, and while holding that lock they check the `_is_shutting_down` variable. If the the JVM indeed is shutting down, the threads refuse to schedule the GC operation.
> 
> Depending on the type of thread that is trying to schedule the GC operation we do one out of two things:
> 
> 1) If it is a Java thread, we simply block the thread from running. The thread is either a daemon thread and the blocking of the thread will not hinder the shutdown. Or, the thread is a non-daemon thread but the Java code called System.halt, which doesn't wait for non-daemon threads.
> 
> 2) If it is a Concurrent GC thread, then we let the thread proceed but with the order to skip the GC operation. This is done because the current shutdown code calls "stop" on the Concurrent GC threads and then wait for them to signal back when they have stopped running their code. So, we need to let them run to completion.
> 
> There are some G1 specific details to look at:
> 
> 1) I've reverted the G1 `concurrent_mark_is_terminating` checks.
> 
> 2) `try_collect_concurrently` queries the `_is_shutting_down` while holding the lock, and then uses that queried value after the lock is released.
> 
> 3) I've left some breadcrumbs in `should_clear_region`. Any suggestions on what to do with the comment and assert?
> 
> This has been ...

This pull request has now been integrated.

Changeset: 5922c3cb
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5922c3cbac43795275422f2484082d1e725e4bcc
Stats:     144 lines in 14 files changed: 46 ins; 66 del; 32 mod

8371990: Remove two second delayed OOME after GC shutdown

Reviewed-by: kbarrett, tschatzl, ayang, iwalulya

-------------

PR: https://git.openjdk.org/jdk/pull/28349

From aartemov at openjdk.org  Fri Nov 21 09:15:40 2025
From: aartemov at openjdk.org (Anton Artemov)
Date: Fri, 21 Nov 2025 09:15:40 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
Message-ID: <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>

On Fri, 21 Nov 2025 07:56:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8366659: Fixed whitespace error.
>
> I'm looking at the  two new tests scenarios. They look non-real and very artificial because the application plays a role of the debugger at the same time and constructs the artificial deadlocks. The threads sync on an application lock, one of them suspends and another resumes the target thread. These deadlocks are impossible to have with any normal debugger which is decoupled from application it is debugging.
> Sorry for saying it but it feels like there is no sense to fix this artificial issue.

Thanks @sspitsyn for diving into the issue. 

With that definition of the deadlock and suspension logic I agree that it might not be a problem at all. With this being said, is the existing test `SuspendWithObjectMonitorWait` demonstrating a real-world scenario? @dcubed-ojdk, what do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3562088599

From mdoerr at openjdk.org  Fri Nov 21 09:33:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 21 Nov 2025 09:33:22 GMT
Subject: RFR: 8333871: Check sysinfo return values [v6]
In-Reply-To: <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
 <azlAK7vPJx4vlSfFzf65IIMollv4Yi6_o2NsX0cbSjs=.d62e19c0-d3f7-4288-b560-90b864187d41@github.com>
Message-ID: <9-x45TvgQNiceY29PMFo7SzGkbIpmw_zqd-u0zhkFy0=.ce905dd2-6966-4506-a966-dcd18da5b491@github.com>

On Thu, 20 Nov 2025 08:27:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
>> However we miss checking the return values at some places, this might need adjustment.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better assert messages

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28317#pullrequestreview-3491880550

From sgehwolf at openjdk.org  Fri Nov 21 09:55:54 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 21 Nov 2025 09:55:54 GMT
Subject: RFR: 8371769: TestMemoryInvisibleParent.java fails
 java.nio.file.AccessDeniedException [v2]
In-Reply-To: <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com>
References: <zFcxfyZig1unRmDYC7AIRB5KOby3rrp6TAbAkXnp6z8=.6bbd6a2a-60e7-4d08-9e13-aaf8dca7dc43@github.com>
 <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com>
Message-ID: <wgnnoGzYIu2KjGqjr1Ner1HYeFa3bghy0Z4adry7ASQ=.187e81d9-7737-4d81-8ba2-46c73d93a255@github.com>

On Mon, 17 Nov 2025 02:45:45 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java fails when run with non-root user. Test will try to write file /sys/fs/cgroup/memory/hidden-parent-TestMemoryInvisibleParent26/memory.limit_in_bytes, and this will make non-root user report java.nio.file.AccessDeniedException. So I think we should skip this test when user is not root.
>> 
>> This PR also add prefix indent for a try block, but do not touch the original logic.
>> 
>> Change has been verified locally on linux-aarch64 with non-root user.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8371769
>  - 8371769: TestMemoryInvisibleParent.java fails java.nio.file.AccessDeniedException

OK

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28286#pullrequestreview-3491972637

From jkratochvil at openjdk.org  Fri Nov 21 10:04:49 2025
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 21 Nov 2025 10:04:49 GMT
Subject: Integrated: 8372135: clang compilation error
In-Reply-To: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
References: <j65q-L9HE2SQkriOYWlR-05JgsFAmE6BqaQeGv6hSKs=.4541d84e-fd87-4361-9ad0-b4cd2fafa544@github.com>
Message-ID: <mPAB_3X6MumH-dqOMbNTQfzPsxofjAoKxOJbQ3Kf69I=.6b527e78-1786-42c4-87d0-6ad72e58e679@github.com>

On Wed, 19 Nov 2025 07:59:32 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> clang-20.1.8-4.fc42.x86_64
> 
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:212:10: error: 'is_containerized' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   212 |     bool is_containerized();
>       |          ^       
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:284:18: note: overridden virtual function is here
>   284 |     virtual bool is_containerized() = 0;
>       |                  ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:214:18: error: 'container_type' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   214 |     const char * container_type() {
>       |                  ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:288:26: note: overridden virtual function is here
>   288 |     virtual const char * container_type() = 0;
>       |                          ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:217:54: error: 'memory_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   217 |     CachingCgroupController<CgroupMemoryController>* memory_controller() { return _memory; }
>       |                                                      ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:289:62: note: overridden virtual function is here
>   289 |     virtual CachingCgroupController<CgroupMemoryController>* memory_controller() = 0;
>       |                                                              ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:218:51: error: 'cpu_controller' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
>   218 |     CachingCgroupController<CgroupCpuController>* cpu_controller() { return _cpu; }
>       |                                                   ^
> src/hotspot/os/linux/cgroupSubsystem_linux.hpp:290:59: note: overridden virtual function is here
>   290 |     virtual CachingCgroupController<CgroupCpuController>* cpu_controller() = 0;
>       |                                                           ^
> In file included from src/hotspot/os/linux/cgroupSubsystem_linux.cpp:27:
> src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp:219:30: error: 'cpuacct_controller' overrides a member function but is not marked...

This pull request has now been integrated.

Changeset: d57fc1b6
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d57fc1b6dc313eb004892b180960ebcee1cb04c7
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8372135: clang compilation error

Reviewed-by: stefank, jsjolen, kbarrett

-------------

PR: https://git.openjdk.org/jdk/pull/28384

From sgehwolf at openjdk.org  Fri Nov 21 10:15:49 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 21 Nov 2025 10:15:49 GMT
Subject: RFR: 8372125: containers/docker/TestPids.java fails after 8365606
In-Reply-To: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
References: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
Message-ID: <Vl3wLgl_O-F9iNvPbqi1R1Osm8LgfuZd63-oz0s9oLo=.b3b1f40d-6296-4a5b-bee1-c200596cdf9a@github.com>

On Wed, 19 Nov 2025 03:20:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test containers/docker/TestPids.java seems to be fails after [JDK-8365606](https://bugs.openjdk.org/browse/JDK-8365606)
> I think max/-1/ulimited are all acceptable as unlimited pids value.
> The change has been verified locally on linux-x64 and linux-aarch64.

LGTM

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28383#pullrequestreview-3492060251

From mbaesken at openjdk.org  Fri Nov 21 11:22:58 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Nov 2025 11:22:58 GMT
Subject: Integrated: 8333871: Check return values of sysinfo
In-Reply-To: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
References: <gpmTA7lunoAlUG0JNEtuZjk_2-r_ZwvmyarNEPqKAOc=.066b8ef6-86be-48f0-8a99-5b1d2121712d@github.com>
Message-ID: <ixPnp23g7xbEELsL7FsWt9DnEhhky6kv9E1B9rMe1z8=.c58fd8e6-8aa5-468f-82ba-06ddc995c245@github.com>

On Fri, 14 Nov 2025 10:33:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> In the review of [JDK-8333522](https://bugs.openjdk.org/browse/JDK-8333522) it has been discussed that we might run into issues because of failing sysinfo.
> However we miss checking the return values at some places, this might need adjustment.

This pull request has now been integrated.

Changeset: 30410fe2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30410fe265d8d32fb41bae88ab882115271cdf75
Stats:     15 lines in 2 files changed: 8 ins; 0 del; 7 mod

8333871: Check return values of sysinfo

Reviewed-by: dholmes, mdoerr, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/28317

From sspitsyn at openjdk.org  Fri Nov 21 11:42:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 21 Nov 2025 11:42:24 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
 <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
Message-ID: <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>

On Fri, 21 Nov 2025 09:11:52 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario?

It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :)
New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3562647847

From mbaesken at openjdk.org  Fri Nov 21 13:09:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 21 Nov 2025 13:09:52 GMT
Subject: RFR: 8372272: Hotspot shared lib loading - add load attempts to
 Events::log
Message-ID: <aJLfOoDzKX7Eb9fjLfbrF-8qBjcvNBYvKj3xU20TJtA=.2d3731a6-e8a5-4ef9-9d2e-eb22c85f8a03@github.com>

Currently we log only the success or failure of shared lib load operations in HS
(by calling Events::log_dll_message).
Adding log messages for load attempts would help us in a number of cases :
- give timestamps before AND after the load operation
- log in hs_err file shared lib loads leading to crashes (there we do not see currently the success or failure of the dlopen operation)

-------------

Commit messages:
 - JDK-8372272

Changes: https://git.openjdk.org/jdk/pull/28452/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28452&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372272
  Stats: 8 lines in 4 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28452/head:pull/28452

PR: https://git.openjdk.org/jdk/pull/28452

From shade at openjdk.org  Fri Nov 21 15:04:16 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Nov 2025 15:04:16 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
Message-ID: <mp97Z9xf-Bz27uxuCnpe7Vp3jjqJBVrIEaG1_UJItQ8=.165932f6-7edf-42e6-a45a-913475dbd8fc@github.com>

On Thu, 20 Nov 2025 01:27:01 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.
> 
> Reverted changes to:
>  -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries
> 
> Testing (in Ubuntu 26.04 i386 chroot):
> 
> $ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
> ...
> $ make images
> Building target 'images' in configuration 'linux-x86-zero-release'
> Warning: No SCM configuration present and no .src-rev
> Updating images/sec-bin.zip
> Finished building target 'images' in configuration 'linux-x86-zero-release'
> $

Thanks, that was indeed too far, and Linux x86_32 Zero is supposed to still work.

src/hotspot/os/linux/os_linux.cpp line 1775:

> 1773: #if  (defined IA32)
> 1774:   static  Elf32_Half running_arch_code=EM_386;
> 1775: #elif   (defined AMD64) || (defined X32)

Do you need `X32` case here? I don't think anything wants it.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28406#pullrequestreview-3493128857
PR Review Comment: https://git.openjdk.org/jdk/pull/28406#discussion_r2550046862

From phubner at openjdk.org  Fri Nov 21 15:12:31 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 21 Nov 2025 15:12:31 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v2]
In-Reply-To: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
Message-ID: <IaZ_fgdcPder2qpk0StmyaGLCKAAlsyZdF5zHVDkM54=.d7ae561b-0cc3-4548-96fc-5c007b7af54e@github.com>

> Hi all,
> 
> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
> 
> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> 
> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
> 
> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # CreateCoredumpOnCrash turned off, no core file dumped
> 
> **Scenario 2: `get_core_path` errors**
> 
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: core.2618391 (may not exist)
> 
> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps are further processed the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
> 
> **Scenario 4: the resource limit for core dumps could not be determined**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>> #
> 
> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>> Java HotSpot(TM) 64-Bit Server VM warni...

Paul H?bner 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 four additional commits since the last revision:

 - Merge branch 'master' into JDK-8368551
 - Update doc.
 - Overhaul some core messages again.
 - Better posix coredump messages.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28174/files
  - new: https://git.openjdk.org/jdk/pull/28174/files/b6d83930..f8fe78a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28174&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28174&range=00-01

  Stats: 238760 lines in 1936 files changed: 162652 ins; 40980 del; 35128 mod
  Patch: https://git.openjdk.org/jdk/pull/28174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28174/head:pull/28174

PR: https://git.openjdk.org/jdk/pull/28174

From phubner at openjdk.org  Fri Nov 21 15:12:32 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 21 Nov 2025 15:12:32 GMT
Subject: RFR: 8368551: Core dump warning may be confusing
In-Reply-To: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
Message-ID: <aEaLmgKQfzxxADqn93ZJeocu035Y4WqUOwVw_TI-Nvs=.071b60aa-af9a-4de6-b1b4-a4303990c054@github.com>

On Thu, 6 Nov 2025 08:51:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
> 
> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> 
> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
> 
> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # CreateCoredumpOnCrash turned off, no core file dumped
> 
> **Scenario 2: `get_core_path` errors**
> 
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: core.2618391 (may not exist)
> 
> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps are further processed the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
> 
> **Scenario 4: the resource limit for core dumps could not be determined**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>> #
> 
> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>> Java HotSpot(TM) 64-Bit Server VM warni...

@dholmes-ora @tstuefe I've taken into account your feedback and refined the messages a bit. I've updated the PR description highlighting all variants. I hope in particular the scenario where the coredump is processed is a bit clearer. I agree on the point that we should probably look into refactoring get_core_path. Perhaps we could do this with three RFEs instead: AIX, BSD and Linux. @tstuefe  if you feel strongly enough about it, feel free to make an RFE (or let me know to make one). I'm happy to take a look, but I don't have knowledge on or hardware for AIX so I'd need support there. 

I'm gonna re-run testing over the weekend; I also merged in the latest mainline changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28174#issuecomment-3563412548

From stuefe at openjdk.org  Fri Nov 21 16:01:18 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 21 Nov 2025 16:01:18 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v2]
In-Reply-To: <IaZ_fgdcPder2qpk0StmyaGLCKAAlsyZdF5zHVDkM54=.d7ae561b-0cc3-4548-96fc-5c007b7af54e@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <IaZ_fgdcPder2qpk0StmyaGLCKAAlsyZdF5zHVDkM54=.d7ae561b-0cc3-4548-96fc-5c007b7af54e@github.com>
Message-ID: <WRb2o_KV-mkUxgmNK-9K_0xkOLTk3m67ITq_9nBNOUk=.c7382dbd-81a8-4717-a76c-39874c53025d@github.com>

On Fri, 21 Nov 2025 15:12:31 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>> 
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.2618391 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps are further processed the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>>> #
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, ...
>
> Paul H?bner 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8368551
>  - Update doc.
>  - Overhaul some core messages again.
>  - Better posix coredump messages.

Okay, thank you.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28174#pullrequestreview-3493398459

From never at openjdk.org  Fri Nov 21 17:14:47 2025
From: never at openjdk.org (Tom Rodriguez)
Date: Fri, 21 Nov 2025 17:14:47 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null
In-Reply-To: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
Message-ID: <DxaVQiXOOVRpYEE6slwjy0RDBZLrL7SPI93rbuVIE1E=.0dcbcae5-8991-4e00-bdba-e04c04e0a970@github.com>

On Thu, 20 Nov 2025 17:00:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
> 
> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
> 
> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
> 
> Tested with submitted reproducer and tier1-4.

Thanks for tracking this down!  Looks good.

src/hotspot/share/classfile/systemDictionary.cpp line 1877:

> 1875:       // resolution succeeded but there's an error in this nest host.
> 1876:       assert(pool->resolved_klass_at(which) != nullptr, "klass is should be resolved if there is no entry");
> 1877:       ResolutionErrorTable::add_entry(pool, which, message);

I might be inclined to swap the cases.

if (entry == nullptr) {
    ...
} else if (entry->nest_host_error() == nullptr) {
    ...
}


Is there ever a situation where replacing an entry in ResolutionErrorTable is correct?  Maybe there should be a check for that somewhere?

-------------

Marked as reviewed by never (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28438#pullrequestreview-3493677260
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2550445406

From iklam at openjdk.org  Fri Nov 21 17:21:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 21 Nov 2025 17:21:56 GMT
Subject: RFR: 8372253: Improve logging to show why a class was excluded
 from AOT Cache
In-Reply-To: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
References: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
Message-ID: <a7m-rmiMEc8aNs-ahq4Uz_uYBwpU6VE4Qu2jdioAxEA=.c6ee6170-d1a8-4181-97fb-c8ae9fa59ca7@github.com>

On Thu, 20 Nov 2025 09:20:11 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

> Fixes: https://bugs.openjdk.org/browse/JDK-8372253
> 
> When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
> [warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification
> 
> 
> This PR improves the log message by adding the cause of this failure:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod

I think we don't need the test in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28413#issuecomment-3563959822

From macarte at openjdk.org  Fri Nov 21 18:41:45 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 18:41:45 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
Message-ID: <ncCCIGiscZD6YF01wG_oNV_0Er3hPqf0DkBs2jIL-ug=.74833746-6082-4ea2-92c4-1af51ced1f6c@github.com>

On Fri, 21 Nov 2025 00:37:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>>  - Corrected placement of assert and logic test
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 57:
> 
>> 55:             try {
>> 56:                 OutputAnalyzer output = ProcessTools.executeProcess(jcmd.getCommand());
>> 57:                 output.shouldContain("AOT.end_recording is unsupported");
> 
> A little bit confused.  The check doesn't match test description.

This test uses Lingered apps (enabling the jcmd connection), however the test framework here doesn't support creating the AOT cache - so I simply check that the connection works and the diagnostic command returns the expected value when you aren't recording a cache

I'm trying to create an additional test that allows jcmd to end training on an AOT recording, but there's some issues merging the jcmd test support and the aot test support;  I will make it clearer in this test about this limitation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550648445

From coleenp at openjdk.org  Fri Nov 21 18:43:29 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Nov 2025 18:43:29 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null
In-Reply-To: <DxaVQiXOOVRpYEE6slwjy0RDBZLrL7SPI93rbuVIE1E=.0dcbcae5-8991-4e00-bdba-e04c04e0a970@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <DxaVQiXOOVRpYEE6slwjy0RDBZLrL7SPI93rbuVIE1E=.0dcbcae5-8991-4e00-bdba-e04c04e0a970@github.com>
Message-ID: <or6jtO6_H2_xn2qfV-kxzRsh6I3sP29Miv921X6NHeA=.39c640ed-dcc8-42bd-83cc-1c96ff972fbf@github.com>

On Fri, 21 Nov 2025 17:10:29 GMT, Tom Rodriguez <never at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1877:
> 
>> 1875:       // resolution succeeded but there's an error in this nest host.
>> 1876:       assert(pool->resolved_klass_at(which) != nullptr, "klass is should be resolved if there is no entry");
>> 1877:       ResolutionErrorTable::add_entry(pool, which, message);
> 
> I might be inclined to swap the cases.
> 
> if (entry == nullptr) {
>     ...
> } else if (entry->nest_host_error() == nullptr) {
>     ...
> }
> 
> 
> Is there ever a situation where replacing an entry in ResolutionErrorTable is correct?  Maybe there should be a check for that somewhere?

Yes, this reorganization would look nicer.
No, there's a never a situation where calling replacing an entry in the ResolutionErrorTable is correct because this HashTable::put() function leaks the value that it has replaced.  I've been testing an assert for this.
In general, this function can leak the value but I did a test and we don't leak anything but this one right now.  But I think we should fix this separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2550655223

From macarte at openjdk.org  Fri Nov 21 18:47:21 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 18:47:21 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
Message-ID: <wGhYdujXMnJXPDNRXQsVdoWeJUHLBUQ_pmHUErcrj2k=.a5621030-3bfa-48de-b992-20890be5de24@github.com>

On Fri, 21 Nov 2025 00:32:48 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>>  - Corrected placement of assert and logic test
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 31:
> 
>> 29:  * @summary Sanity test for Jcmd AOT.end_recording command
>> 30:  * @library /test/lib
>> 31:  * @build JcmdAOTEndRecordingTest
> 
> No need to build test explicitly, jtreg does it by itself.

Thank you, I did not know that (copied another test as a template) - I've removed the build step in the header of both tests

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550662386

From macarte at openjdk.org  Fri Nov 21 18:56:57 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 18:56:57 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
Message-ID: <RqmQ9_UJpI5Wj4Axl1XwQm5S9vE09Zs3q0XYNvdGmP0=.92f71df8-6069-418a-bf5f-cf468ab6e617@github.com>

On Fri, 21 Nov 2025 00:56:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8370203' of https://github.com/macarte/jdk into JDK-8370203
>>  - Corrected placement of assert and logic test
>
> src/hotspot/share/cds/aotMetaspace.cpp line 1062:
> 
>> 1060: bool AOTMetaspace::preimage_static_archive_dumped() {
>> 1061:   assert(CDSConfig::is_dumping_preimage_static_archive(), "Required");
>> 1062:   return _preimage_static_archive_dumped == 1;
> 
> Should it be  AtomicAccess::load(&_preimage_static_archive_dumped) here?

Andrew brought this up also; I'll add but should it be AtomicAccess::load or AtomicAccess::load_acquire?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550681782

From coleenp at openjdk.org  Fri Nov 21 18:57:28 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 21 Nov 2025 18:57:28 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
Message-ID: <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>

> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
> 
> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
> 
> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
> 
> Tested with submitted reproducer and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Reorder if statement and add an assert.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28438/files
  - new: https://git.openjdk.org/jdk/pull/28438/files/6123316c..8e7be57d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=00-01

  Stats: 14 lines in 2 files changed: 7 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28438/head:pull/28438

PR: https://git.openjdk.org/jdk/pull/28438

From macarte at openjdk.org  Fri Nov 21 19:12:25 2025
From: macarte at openjdk.org (Mat Carter)
Date: Fri, 21 Nov 2025 19:12:25 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <73mIYRuGWI0kSUKqXQdb7MPjZqXwM9s4-EuZw6qeiWo=.8814d782-f332-4033-b43b-7317a82c8650@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <n2LclQT38NOWQE0fymzmKJuHjwMeLrYCqK0xGmzP9TU=.16b3d8f4-fde0-4966-ba0e-1a52f09f605d@github.com>
 <73mIYRuGWI0kSUKqXQdb7MPjZqXwM9s4-EuZw6qeiWo=.8814d782-f332-4033-b43b-7317a82c8650@github.com>
Message-ID: <FCKfnUyVcK9seaHtR0bKACMbElt9_LJuiz2Y5CVOLRE=.f3ec3513-dcaa-4c0d-bd4c-837106ccfc16@github.com>

On Tue, 28 Oct 2025 16:57:43 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/hotspot/share/cds/aotMetaspace.cpp line 963:
>> 
>>> 961: bool AOTMetaspace::is_recording_preimage_static_archive() {
>>> 962:   if (CDSConfig::is_dumping_preimage_static_archive()) {
>>> 963:       return _preimage_static_archive_dumped == 0;
>> 
>> Do we need to use an acquiring load here? i.e. can the read here and the cmpxchg below happen in different threads?
>> n.b. I'm not just thinking about the behaviour when this patch makes the DCmd available but also what happens when we supplement it with the MXBean interface to end recordings.
>
> I think it's okay, as ending the recording is controlled by the cmpxchg, even if two threads think the recording is still going on, only one call to end the recording will work, and if the threads both check whether the recording has completed they will both see that it has (regardless of which thread 'won')

Andrew I'm going to add the AtomicAccess::load_acquire, or would AtomicAccess::load be enough

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2550719327

From iklam at openjdk.org  Sat Nov 22 01:08:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 22 Nov 2025 01:08:23 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
Message-ID: <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>

On Fri, 21 Nov 2025 18:57:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reorder if statement and add an assert.

src/hotspot/share/classfile/resolutionErrors.cpp line 90:

> 88:   bool created = false;
> 89:   _resolution_error_table->put_if_absent(key, entry, &created);
> 90:   assert(created, "should be created not updated");

The above 3 lines can be replaced with `_resolution_error_table->put_when_absent(key, entry)`.

src/hotspot/share/classfile/systemDictionary.cpp line 1870:

> 1868:       // Only add a new resolution error if one hasn't been found for this constant pool index. In this case,
> 1869:       // resolution succeeded but there's an error in this nest host.
> 1870:       assert(pool->resolved_klass_at(which) != nullptr, "klass is should be resolved if there is no entry");

typo: `"klass should be resolved ...`

src/hotspot/share/classfile/systemDictionary.cpp line 1877:

> 1875:       // only reach here under the same error condition, so we can ignore the potential race with setting
> 1876:       // the message. If we see it is already set then we can ignore it.
> 1877:       entry->set_nest_host_error(message);

Existing -- shouldn't we free the old `entry->_nest_host_error`?

Also, there's a related memory leak here:


// Add entry to resolution error table to record the error when the first
// attempt to resolve a reference to a class has failed.
void SystemDictionary::add_resolution_error(const constantPoolHandle& pool, int which,
                                            Symbol* error, const char* message,
                                            Symbol* cause, const char* cause_msg) {
  {
    MutexLocker ml(Thread::current(), SystemDictionary_lock);
    ResolutionErrorEntry* entry = ResolutionErrorTable::find_entry(pool, which);
    if (entry == nullptr) {
      ResolutionErrorTable::add_entry(pool, which, error, message, cause, cause_msg);
    } else {
        // message and cause_msg are leaked <<<<<<<<<<
    }
  }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2551404434
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2551510022
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2551420213

From jsjolen at openjdk.org  Sat Nov 22 10:16:02 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Sat, 22 Nov 2025 10:16:02 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
Message-ID: <xkSuBAfZV3EGECFif03Jsg-IpnBo9cY00e3n96AemiA=.3ed6473a-b0ea-49a9-b1cb-62d0ce6507d3@github.com>

On Sat, 22 Nov 2025 00:30:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorder if statement and add an assert.
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1877:
> 
>> 1875:       // only reach here under the same error condition, so we can ignore the potential race with setting
>> 1876:       // the message. If we see it is already set then we can ignore it.
>> 1877:       entry->set_nest_host_error(message);
> 
> Existing -- shouldn't we free the old `entry->_nest_host_error`?
> 
> Also, there's a related memory leak here:
> 
> 
> // Add entry to resolution error table to record the error when the first
> // attempt to resolve a reference to a class has failed.
> void SystemDictionary::add_resolution_error(const constantPoolHandle& pool, int which,
>                                             Symbol* error, const char* message,
>                                             Symbol* cause, const char* cause_msg) {
>   {
>     MutexLocker ml(Thread::current(), SystemDictionary_lock);
>     ResolutionErrorEntry* entry = ResolutionErrorTable::find_entry(pool, which);
>     if (entry == nullptr) {
>       ResolutionErrorTable::add_entry(pool, which, error, message, cause, cause_msg);
>     } else {
>         // message and cause_msg are leaked <<<<<<<<<<
>     }
>   }
> }

In the `SystemDictionary` case, we're fine. You wouldn't think so, but we are. That's because message and cause_msg are resource allocated, and those strings are strdup:ed in the constructor of the table entry. `InstanceKlass::next_host` has a memory leak though, because `ResolutionErrorEntry` *does* take ownership of the underlying string pointer, so we have this:

```c++
      const char* msg = ss.as_string(true /* on C-heap */);
      constantPoolHandle cph(THREAD, constants());
      SystemDictionary::add_nest_host_error(cph, _nest_host_index, msg);
      // ... down the callstack we go, reaching the constructor call:
       ResolutionErrorEntry *entry = new ResolutionErrorEntry(message);
       ResolutionErrorEntry(const char* message):
        _error(nullptr),
        _message(nullptr),
        _cause(nullptr),
        _cause_msg(nullptr),

        _nest_host_error(message) {} // <-- Noooo


As opposed to the other constructor, which looks like this:

```c++
// This is the call to the constructor this time:
  ResolutionErrorEntry *entry = new ResolutionErrorEntry(error, message, cause, cause_msg);
ResolutionErrorEntry::ResolutionErrorEntry(Symbol* error, const char* message,
                                           Symbol* cause, const char* cause_msg):
        _error(error),
        _message(message != nullptr ? os::strdup(message) : nullptr),
        _cause(cause),
        _cause_msg(cause_msg != nullptr ? os::strdup(cause_msg) : nullptr),
        _nest_host_error(nullptr) {

  Symbol::maybe_increment_refcount(_error);
  Symbol::maybe_increment_refcount(_cause);
}


This is actually pretty bad :-/, I'd really appreciate it if we could make these types of bugs a bit more shallow at the time of writing them.

Maybe it'd be nice to have a type that tells the reader that an object doesn't intend to free a received pointer on its destruction? This is a very small sketch of something illustrating kind of what I mean:

```c++
template<typename T>
using Borrow = T*;
template<typename T>
using Own = T*;

// "I'll take a string, but I don't intend to be responsible for freeing it"
const char* os::strdup(Borrow<const char>, MemTag) { /* ... */}

class SystemDictionary {
  Own<const char> _message; // I own this, and so I intend to free it when I'm destroyed
  Own<const char> _cause_msg; // Same here

  // "I'll take a message and a cause_msg, and I won't be responsible for freeing it"
  void SystemDictionary::add_resolution_error(const constantPoolHandle& pool, int which,
                                            Symbol* error, Borrow<const char> message,
                                            Symbol* cause, Borrow<const char> cause_msg) : 
  // Reader meant to think: Wait, we're assigning a Borrow to an Own directly? Seems wrong.
    _message(message),
// Reader meant to think: Aah, we're making a copy to get ownership
   _cause_msg(os::strdup(cause_msg)) 
{
  /* ... */
}
};


This will make no compiler errors for us in case of incorrect usage, but it will be a sign to the reader that `SystemDictionary` doesn't intend to clean up `message` or `cause_msg`, and that the writer actually thought about the possibility of a leak from these strings.

**I'm not suggesting this is what we add,** I'm just saying that clearly we can communicate more in the code than we currently do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2552861538

From jsjolen at openjdk.org  Sat Nov 22 12:02:34 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Sat, 22 Nov 2025 12:02:34 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <xkSuBAfZV3EGECFif03Jsg-IpnBo9cY00e3n96AemiA=.3ed6473a-b0ea-49a9-b1cb-62d0ce6507d3@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
 <xkSuBAfZV3EGECFif03Jsg-IpnBo9cY00e3n96AemiA=.3ed6473a-b0ea-49a9-b1cb-62d0ce6507d3@github.com>
Message-ID: <NxsfsUR-de39aCb9hWqhnJrvc8zZYnsK9YICN6388ag=.b5069d4f-5b1e-4d1d-8e00-b746e6fbe4c6@github.com>

On Sat, 22 Nov 2025 10:12:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.cpp line 1877:
>> 
>>> 1875:       // only reach here under the same error condition, so we can ignore the potential race with setting
>>> 1876:       // the message. If we see it is already set then we can ignore it.
>>> 1877:       entry->set_nest_host_error(message);
>> 
>> Existing -- shouldn't we free the old `entry->_nest_host_error`?
>> 
>> Also, there's a related memory leak here:
>> 
>> 
>> // Add entry to resolution error table to record the error when the first
>> // attempt to resolve a reference to a class has failed.
>> void SystemDictionary::add_resolution_error(const constantPoolHandle& pool, int which,
>>                                             Symbol* error, const char* message,
>>                                             Symbol* cause, const char* cause_msg) {
>>   {
>>     MutexLocker ml(Thread::current(), SystemDictionary_lock);
>>     ResolutionErrorEntry* entry = ResolutionErrorTable::find_entry(pool, which);
>>     if (entry == nullptr) {
>>       ResolutionErrorTable::add_entry(pool, which, error, message, cause, cause_msg);
>>     } else {
>>         // message and cause_msg are leaked <<<<<<<<<<
>>     }
>>   }
>> }
>
> In the `SystemDictionary` case, we're fine. You wouldn't think so, but we are. That's because message and cause_msg are resource allocated, and those strings are strdup:ed in the constructor of the table entry. `InstanceKlass::next_host` has a memory leak though, because `ResolutionErrorEntry` *does* take ownership of the underlying string pointer, so we have this:
> 
> ```c++
>       const char* msg = ss.as_string(true /* on C-heap */);
>       constantPoolHandle cph(THREAD, constants());
>       SystemDictionary::add_nest_host_error(cph, _nest_host_index, msg);
>       // ... down the callstack we go, reaching the constructor call:
>        ResolutionErrorEntry *entry = new ResolutionErrorEntry(message);
>        ResolutionErrorEntry(const char* message):
>         _error(nullptr),
>         _message(nullptr),
>         _cause(nullptr),
>         _cause_msg(nullptr),
> 
>         _nest_host_error(message) {} // <-- Noooo
> 
> 
> As opposed to the other constructor, which looks like this:
> 
> ```c++
> // This is the call to the constructor this time:
>   ResolutionErrorEntry *entry = new ResolutionErrorEntry(error, message, cause, cause_msg);
> ResolutionErrorEntry::ResolutionErrorEntry(Symbol* error, const char* message,
>                                            Symbol* cause, const char* cause_msg):
>         _error(error),
>         _message(message != nullptr ? os::strdup(message) : nullptr),
>         _cause(cause),
>         _cause_msg(cause_msg != nullptr ? os::strdup(cause_msg) : nullptr),
>         _nest_host_error(nullptr) {
> 
>   Symbol::maybe_increment_refcount(_error);
>   Symbol::maybe_increment_refcount(_cause);
> }
> 
> 
> This is actually pretty bad :-/, I'd really appreciate it if we could make these types of bugs a bit more shallow at the time of writing them.
> 
> Maybe it'd be nice to have a type that tells the reader that an object doesn't intend to free a received pointer on its destruction? This is a very small sketch of something illustrating kind of what I mean:
> 
> ```c++
> template<typename T>
> using Borrow = T*;
> template<typename T>
> using Own = T*;
> 
> // "I'll take a string, but I don't intend to be responsible for freeing it"
> const char* os::strdup(Borrow<const char>, MemTag) { /* ... */}
> 
> class SystemDictionary {
>   Own<const char> _message; // I own this, and so I intend to free it when I'm destroyed
>   Own<const char> _cause_msg; // Same here
> 
>   // "I'll take a message and a cause_msg, and I won't be responsible for freeing it"
>   void SystemDictionary::add_resolution_error(const constantPoolHandle& p...

I made a ticket for this: [8372373](https://bugs.openjdk.org/browse/JDK-8372373)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2553100145

From coleenp at openjdk.org  Sat Nov 22 22:07:20 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 22 Nov 2025 22:07:20 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v3]
In-Reply-To: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
Message-ID: <rkav1oDRh9TAdn8sV0oV4qZ5S5GvLOeA_cjkZTUrer0=.ba80d0ff-b4bd-4f2e-b361-8baa935909dc@github.com>

> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
> 
> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
> 
> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
> 
> Tested with submitted reproducer and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28438/files
  - new: https://git.openjdk.org/jdk/pull/28438/files/8e7be57d..8d30c17d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28438/head:pull/28438

PR: https://git.openjdk.org/jdk/pull/28438

From coleenp at openjdk.org  Sat Nov 22 22:07:23 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 22 Nov 2025 22:07:23 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
Message-ID: <X9wJ3Its78BTbwHOWKZNKo-zQHatArJ7IpWiUlAjdNg=.1ea93714-56a0-44f3-8281-a3def5872caa@github.com>

On Sat, 22 Nov 2025 00:26:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reorder if statement and add an assert.
>
> src/hotspot/share/classfile/resolutionErrors.cpp line 90:
> 
>> 88:   bool created = false;
>> 89:   _resolution_error_table->put_if_absent(key, entry, &created);
>> 90:   assert(created, "should be created not updated");
> 
> The above 3 lines can be replaced with `_resolution_error_table->put_when_absent(key, entry)`.

If I use that, I lose the ability to assert that the new entry was created and not already found, which I really want.

> src/hotspot/share/classfile/systemDictionary.cpp line 1870:
> 
>> 1868:       // Only add a new resolution error if one hasn't been found for this constant pool index. In this case,
>> 1869:       // resolution succeeded but there's an error in this nest host.
>> 1870:       assert(pool->resolved_klass_at(which) != nullptr, "klass is should be resolved if there is no entry");
> 
> typo: `"klass should be resolved ...`

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2553372900
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2553374890

From coleenp at openjdk.org  Sat Nov 22 22:07:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 22 Nov 2025 22:07:24 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <NxsfsUR-de39aCb9hWqhnJrvc8zZYnsK9YICN6388ag=.b5069d4f-5b1e-4d1d-8e00-b746e6fbe4c6@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
 <xkSuBAfZV3EGECFif03Jsg-IpnBo9cY00e3n96AemiA=.3ed6473a-b0ea-49a9-b1cb-62d0ce6507d3@github.com>
 <NxsfsUR-de39aCb9hWqhnJrvc8zZYnsK9YICN6388ag=.b5069d4f-5b1e-4d1d-8e00-b746e6fbe4c6@github.com>
Message-ID: <71uwWoechKU6BOvvnUyFOAqNW6oB1Kl8rYJRkArO0Ek=.dc2e5a41-95d0-43e3-b38e-99ce138d0537@github.com>

On Sat, 22 Nov 2025 11:58:49 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> In the `SystemDictionary` case, we're fine. You wouldn't think so, but we are. That's because message and cause_msg are resource allocated, and those strings are strdup:ed in the constructor of the table entry. `InstanceKlass::next_host` has a memory leak though, because `ResolutionErrorEntry` *does* take ownership of the underlying string pointer, so we have this:
>> 
>> ```c++
>>       const char* msg = ss.as_string(true /* on C-heap */);
>>       constantPoolHandle cph(THREAD, constants());
>>       SystemDictionary::add_nest_host_error(cph, _nest_host_index, msg);
>>       // ... down the callstack we go, reaching the constructor call:
>>        ResolutionErrorEntry *entry = new ResolutionErrorEntry(message);
>>        ResolutionErrorEntry(const char* message):
>>         _error(nullptr),
>>         _message(nullptr),
>>         _cause(nullptr),
>>         _cause_msg(nullptr),
>> 
>>         _nest_host_error(message) {} // <-- Noooo
>> 
>> 
>> As opposed to the other constructor, which looks like this:
>> 
>> ```c++
>> // This is the call to the constructor this time:
>>   ResolutionErrorEntry *entry = new ResolutionErrorEntry(error, message, cause, cause_msg);
>> ResolutionErrorEntry::ResolutionErrorEntry(Symbol* error, const char* message,
>>                                            Symbol* cause, const char* cause_msg):
>>         _error(error),
>>         _message(message != nullptr ? os::strdup(message) : nullptr),
>>         _cause(cause),
>>         _cause_msg(cause_msg != nullptr ? os::strdup(cause_msg) : nullptr),
>>         _nest_host_error(nullptr) {
>> 
>>   Symbol::maybe_increment_refcount(_error);
>>   Symbol::maybe_increment_refcount(_cause);
>> }
>> 
>> 
>> This is actually pretty bad :-/, I'd really appreciate it if we could make these types of bugs a bit more shallow at the time of writing them.
>> 
>> Maybe it'd be nice to have a type that tells the reader that an object doesn't intend to free a received pointer on its destruction? This is a very small sketch of something illustrating kind of what I mean:
>> 
>> ```c++
>> template<typename T>
>> using Borrow = T*;
>> template<typename T>
>> using Own = T*;
>> 
>> // "I'll take a string, but I don't intend to be responsible for freeing it"
>> const char* os::strdup(Borrow<const char>, MemTag) { /* ... */}
>> 
>> class SystemDictionary {
>>   Own<const char> _message; // I own this, and so I intend to free it when I'm destroyed
>>   Own<const char> _cause_msg; // Same here
>> 
>>   // "I'll take a message and a cause_msg, and I won'...
>
> I made a ticket for this: [8372373](https://bugs.openjdk.org/browse/JDK-8372373)

As Johan said in the first case, the message and cause are resource allocated so not owned by the ResolvedErrorEntry, so that's not a leak.  I have to read the code around the nest host error again to comment.  I would not like this strange template around ownership.

Also, set_nest_host_error() does not need to free the existing error because it's only set if it's null.  So nothing to free.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2553375687

From coleenp at openjdk.org  Sat Nov 22 22:16:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sat, 22 Nov 2025 22:16:50 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <71uwWoechKU6BOvvnUyFOAqNW6oB1Kl8rYJRkArO0Ek=.dc2e5a41-95d0-43e3-b38e-99ce138d0537@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
 <xkSuBAfZV3EGECFif03Jsg-IpnBo9cY00e3n96AemiA=.3ed6473a-b0ea-49a9-b1cb-62d0ce6507d3@github.com>
 <NxsfsUR-de39aCb9hWqhnJrvc8zZYnsK9YICN6388ag=.b5069d4f-5b1e-4d1d-8e00-b746e6fbe4c6@github.com>
 <71uwWoechKU6BOvvnUyFOAqNW6oB1Kl8rYJRkArO0Ek=.dc2e5a41-95d0-43e3-b38e-99ce138d0537@github.com>
Message-ID: <ftqIx7XT2qV-3Edm5Uqn42e2edxv6nQ6OaPfzxD3I7Q=.6d85be98-0e68-4d90-9a97-784ce7eba8d4@github.com>

On Sat, 22 Nov 2025 22:03:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I made a ticket for this: [8372373](https://bugs.openjdk.org/browse/JDK-8372373)
>
> As Johan said in the first case, the message and cause are resource allocated so not owned by the ResolvedErrorEntry, so that's not a leak.  I have to read the code around the nest host error again to comment.  I would not like this strange template around ownership.
> 
> Also, set_nest_host_error() does not need to free the existing error because it's only set if it's null.  So nothing to free.

In my change, the case that ignores setting the nest_host_error should free it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2553379533

From syan at openjdk.org  Sun Nov 23 14:56:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Nov 2025 14:56:29 GMT
Subject: RFR: 8372125: containers/docker/TestPids.java fails after 8365606
In-Reply-To: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
References: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
Message-ID: <t2SmsShxvD9T8W9YdOXetfdRFL6ZKQetlxxMXuWkIlc=.439bf38f-c11f-46e6-8a53-95a30f52a504@github.com>

On Wed, 19 Nov 2025 03:20:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test containers/docker/TestPids.java seems to be fails after [JDK-8365606](https://bugs.openjdk.org/browse/JDK-8365606)
> I think max/-1/ulimited are all acceptable as unlimited pids value.
> The change has been verified locally on linux-x64 and linux-aarch64.

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28383#issuecomment-3568036103

From syan at openjdk.org  Sun Nov 23 14:56:30 2025
From: syan at openjdk.org (SendaoYan)
Date: Sun, 23 Nov 2025 14:56:30 GMT
Subject: Integrated: 8372125: containers/docker/TestPids.java fails after
 8365606
In-Reply-To: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
References: <Ped6cO6AWtjwsibE2pqOwzb8i12lS5WxK98eOhiuKM8=.674487ad-bcb6-43a3-8dd4-3a364530a1b3@github.com>
Message-ID: <XVrM7a9QoBBDZgnQydVpWWb3hakbmNqXddMm_zN4d9k=.dab31a30-a393-4559-a566-13db34eb1a4c@github.com>

On Wed, 19 Nov 2025 03:20:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The test containers/docker/TestPids.java seems to be fails after [JDK-8365606](https://bugs.openjdk.org/browse/JDK-8365606)
> I think max/-1/ulimited are all acceptable as unlimited pids value.
> The change has been verified locally on linux-x64 and linux-aarch64.

This pull request has now been integrated.

Changeset: d3328b4b
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3328b4bd0b2c2b03b4aaf7ebe929c14c4186402
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8372125: containers/docker/TestPids.java fails after 8365606

Reviewed-by: cnorrbin, sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/28383

From coleenp at openjdk.org  Sun Nov 23 18:48:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Sun, 23 Nov 2025 18:48:48 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v4]
In-Reply-To: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
Message-ID: <Z-zYFRgTqD4CJolyJEtDsoYccL5j5-OIiGSFFF2L7xA=.8cf940f1-3dd1-4e36-9d7a-835477790aef@github.com>

> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
> 
> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
> 
> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
> 
> Tested with submitted reproducer and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  I like this version better.  Unconditionally set the nest_host_error even if one exists, and free the existing one.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28438/files
  - new: https://git.openjdk.org/jdk/pull/28438/files/8d30c17d..c959cfe7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=02-03

  Stats: 16 lines in 3 files changed: 9 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28438/head:pull/28438

PR: https://git.openjdk.org/jdk/pull/28438

From vpetko at openjdk.org  Sun Nov 23 19:28:48 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Sun, 23 Nov 2025 19:28:48 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <mp97Z9xf-Bz27uxuCnpe7Vp3jjqJBVrIEaG1_UJItQ8=.165932f6-7edf-42e6-a45a-913475dbd8fc@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
 <mp97Z9xf-Bz27uxuCnpe7Vp3jjqJBVrIEaG1_UJItQ8=.165932f6-7edf-42e6-a45a-913475dbd8fc@github.com>
Message-ID: <hYNegdbEJE1eVmiLMWdzGPMXi9ZNZh9YPgrI4aCKh5E=.374bff21-1950-401a-9c70-fa4ca5975d9d@github.com>

On Fri, 21 Nov 2025 15:00:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.
>> 
>> Reverted changes to:
>>  -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries
>> 
>> Testing (in Ubuntu 26.04 i386 chroot):
>> 
>> $ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
>> ...
>> $ make images
>> Building target 'images' in configuration 'linux-x86-zero-release'
>> Warning: No SCM configuration present and no .src-rev
>> Updating images/sec-bin.zip
>> Finished building target 'images' in configuration 'linux-x86-zero-release'
>> $
>
> src/hotspot/os/linux/os_linux.cpp line 1775:
> 
>> 1773: #if  (defined IA32)
>> 1774:   static  Elf32_Half running_arch_code=EM_386;
>> 1775: #elif   (defined AMD64) || (defined X32)
> 
> Do you need `X32` case here? I don't think anything wants it.

I think Debian wants it:
``Architecture: alpha amd64 arc armel armhf arm64 hppa i386 ia64 loong64 mips mipsel mips64 mips64el powerpc ppc64 ppc64el m68k riscv64 sh4 sparc sparc64 s390x x32``[1]

[1] https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/control?ref_type=heads#L39

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28406#discussion_r2554273480

From iklam at openjdk.org  Sun Nov 23 21:26:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 23 Nov 2025 21:26:48 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <X9wJ3Its78BTbwHOWKZNKo-zQHatArJ7IpWiUlAjdNg=.1ea93714-56a0-44f3-8281-a3def5872caa@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
 <X9wJ3Its78BTbwHOWKZNKo-zQHatArJ7IpWiUlAjdNg=.1ea93714-56a0-44f3-8281-a3def5872caa@github.com>
Message-ID: <PwGyMwhe8hhtv3sAQyqoa2WESL_7yIAT2A4TsiyYh4k=.fcea8a81-9476-44f8-b413-7279ad31a398@github.com>

On Sat, 22 Nov 2025 21:55:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/resolutionErrors.cpp line 90:
>> 
>>> 88:   bool created = false;
>>> 89:   _resolution_error_table->put_if_absent(key, entry, &created);
>>> 90:   assert(created, "should be created not updated");
>> 
>> The above 3 lines can be replaced with `_resolution_error_table->put_when_absent(key, entry)`.
>
> If I use that, I lose the ability to assert that the new entry was created and not already found, which I really want.

`put_when_absent` means "put it in the table when I know it's absent". It already has the assert that you want.

https://github.com/openjdk/jdk/blob/e18e95ed11c1df7eeb162c2303f027564ed6f6aa/src/hotspot/share/utilities/hashTable.hpp#L149-L152

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2554332131

From dholmes at openjdk.org  Mon Nov 24 01:34:33 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Nov 2025 01:34:33 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
 <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
 <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
Message-ID: <AVT1wREU7BFMhtmv1zulfmbPlmPURe4qfcehfMILeDY=.d4cdcaa7-9726-48f6-8730-7f5b0dc57532@github.com>

On Fri, 21 Nov 2025 11:38:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks @sspitsyn for diving into the issue. 
>> 
>> With that definition of the deadlock and suspension logic I agree that it might not be a problem at all. With this being said, is the existing test `SuspendWithObjectMonitorWait` demonstrating a real-world scenario? @dcubed-ojdk, what do you think?
>
>> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario?
> 
> It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :)
> New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them.

@sspitsyn  so your position is that it is okay for suspension to cause something to break as long as resuming the suspended thread then fixes things? Does it matter how much time passes?

We have had a lot of discussion about this outside the PR and some of us at least feel there is a distinction between suspending a thread that clearly holds an application level resource (like a monitor) which then prevents other threads from continuing, versus suspending a thread holding a VM internal "resource" that prevents other threads from continuing. The design of JVM TI thread suspension actively tries to minimise the ability to hold any internal VM resource whilst suspended, and the current problem seems a variant of that. If we suspend a thread that has not yet acquired a monitor, and inspection of the monitor would show it is not owned, then it seems a bug if other threads trying to acquire that monitor can not make progress.

Agreed the tests are completely artificial but there is no way to test this other than to do that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3568649410

From dholmes at openjdk.org  Mon Nov 24 01:45:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Nov 2025 01:45:04 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v2]
In-Reply-To: <IaZ_fgdcPder2qpk0StmyaGLCKAAlsyZdF5zHVDkM54=.d7ae561b-0cc3-4548-96fc-5c007b7af54e@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <IaZ_fgdcPder2qpk0StmyaGLCKAAlsyZdF5zHVDkM54=.d7ae561b-0cc3-4548-96fc-5c007b7af54e@github.com>
Message-ID: <8a-zXXvD21lIjPgL6TD9yEHVCK6feOa5-BrQMEcx820=.49a8037e-57d4-4e38-8f83-5221cc3bda57@github.com>

On Fri, 21 Nov 2025 15:12:31 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>> 
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.2618391 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps are further processed the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>>> #
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, ...
>
> Paul H?bner 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8368551
>  - Update doc.
>  - Overhaul some core messages again.
>  - Better posix coredump messages.

A further suggested wording tweak. Could you give some full examples of the updated messages? Thanks

src/hotspot/os/posix/os_posix.cpp line 129:

> 127:     } else if (core_path[0] == '"') { // redirect to user process
> 128:       if (check_only) {
> 129:         buf.print("core dumps are further processed the following: ");

Suggestion:

        buf.print("core dumps are further processed by the following: ");

or, given these processors are often disabled even if stored in the pattern:

        buf.print("core dumps may be further processed by the following: ");

-------------

PR Review: https://git.openjdk.org/jdk/pull/28174#pullrequestreview-3498171769
PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2554483066

From shade at openjdk.org  Mon Nov 24 07:56:21 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Nov 2025 07:56:21 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <hYNegdbEJE1eVmiLMWdzGPMXi9ZNZh9YPgrI4aCKh5E=.374bff21-1950-401a-9c70-fa4ca5975d9d@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
 <mp97Z9xf-Bz27uxuCnpe7Vp3jjqJBVrIEaG1_UJItQ8=.165932f6-7edf-42e6-a45a-913475dbd8fc@github.com>
 <hYNegdbEJE1eVmiLMWdzGPMXi9ZNZh9YPgrI4aCKh5E=.374bff21-1950-401a-9c70-fa4ca5975d9d@github.com>
Message-ID: <2bhz_h_sXBJYvsc6pzmpt30nLNyigAVJ9U-2y-Ig7H0=.631f8a33-8c69-4ec1-b66a-df174e20c9ba@github.com>

On Sun, 23 Nov 2025 19:24:27 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 1775:
>> 
>>> 1773: #if  (defined IA32)
>>> 1774:   static  Elf32_Half running_arch_code=EM_386;
>>> 1775: #elif   (defined AMD64) || (defined X32)
>> 
>> Do you need `X32` case here? I don't think anything wants it.
>
> I think Debian wants it:
> ``Architecture: alpha amd64 arc armel armhf arm64 hppa i386 ia64 loong64 mips mipsel mips64 mips64el powerpc ppc64 ppc64el m68k riscv64 sh4 sparc sparc64 s390x x32``[1]
> 
> [1] https://salsa.debian.org/openjdk-team/openjdk/-/blob/master/debian/control?ref_type=heads#L39

Oh, all right then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28406#discussion_r2554976865

From mbaesken at openjdk.org  Mon Nov 24 07:58:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 24 Nov 2025 07:58:56 GMT
Subject: RFR: 8372272: Hotspot shared lib loading - add load attempts to
 Events::log
In-Reply-To: <aJLfOoDzKX7Eb9fjLfbrF-8qBjcvNBYvKj3xU20TJtA=.2d3731a6-e8a5-4ef9-9d2e-eb22c85f8a03@github.com>
References: <aJLfOoDzKX7Eb9fjLfbrF-8qBjcvNBYvKj3xU20TJtA=.2d3731a6-e8a5-4ef9-9d2e-eb22c85f8a03@github.com>
Message-ID: <f8C5BUz_AMjjAHot-04bMDg7Ob57pmj2MlZVMjnTQ9w=.388dbb64-617b-4fee-8215-1da230d294c6@github.com>

On Fri, 21 Nov 2025 13:03:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we log only the success or failure of shared lib load operations in HS
> (by calling Events::log_dll_message).
> Adding log messages for load attempts would help us in a number of cases :
> - give timestamps before AND after the load operation
> - log in hs_err file shared lib loads leading to crashes (there we do not see currently the success or failure of the dlopen operation)

Some failures in com/sun/crypto/provider/Cipher/HPKE/KAT9180 , most likely unrelated .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28452#issuecomment-3569383368

From duke at openjdk.org  Mon Nov 24 08:07:15 2025
From: duke at openjdk.org (duke)
Date: Mon, 24 Nov 2025 08:07:15 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
Message-ID: <Cli9FQxDx9gu_g3AFb_gi-vRR_pTQdQoDTDDKjVn2QU=.ff7bdcdf-ae33-4968-9edb-199886737820@github.com>

On Thu, 20 Nov 2025 01:27:01 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.
> 
> Reverted changes to:
>  -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries
> 
> Testing (in Ubuntu 26.04 i386 chroot):
> 
> $ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
> ...
> $ make images
> Building target 'images' in configuration 'linux-x86-zero-release'
> Warning: No SCM configuration present and no .src-rev
> Updating images/sec-bin.zip
> Finished building target 'images' in configuration 'linux-x86-zero-release'
> $

@vpa1977 
Your change (at version 2f55fbe1b183b432ed56e9603a736ceb802ed903) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28406#issuecomment-3569409774

From shade at openjdk.org  Mon Nov 24 08:11:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Nov 2025 08:11:53 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
Message-ID: <My142zxTic_26_95wNTZe8zsVSbe3WAbhlCJbFFDrhI=.5bd301df-0329-45d7-a84d-382de9cddc48@github.com>

On Thu, 20 Nov 2025 01:27:01 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.
> 
> Reverted changes to:
>  -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries
> 
> Testing (in Ubuntu 26.04 i386 chroot):
> 
> $ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
> ...
> $ make images
> Building target 'images' in configuration 'linux-x86-zero-release'
> Warning: No SCM configuration present and no .src-rev
> Updating images/sec-bin.zip
> Finished building target 'images' in configuration 'linux-x86-zero-release'
> $

Technically needs a second Reviewer. Let's see if @anton-seoane is around? Maybe someone else can provide a second review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28406#issuecomment-3569420991

From aseoane at openjdk.org  Mon Nov 24 08:57:50 2025
From: aseoane at openjdk.org (Anton Seoane Ampudia)
Date: Mon, 24 Nov 2025 08:57:50 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
Message-ID: <Xa_2NhpyiKSsApXnk8ooA-yr0lRcyhsR8d-Vh4oToAk=.29a0453e-493f-47fb-bc6a-50a66b14616c@github.com>

On Thu, 20 Nov 2025 01:27:01 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.
> 
> Reverted changes to:
>  -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries
> 
> Testing (in Ubuntu 26.04 i386 chroot):
> 
> $ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
> ...
> $ make images
> Building target 'images' in configuration 'linux-x86-zero-release'
> Warning: No SCM configuration present and no .src-rev
> Updating images/sec-bin.zip
> Finished building target 'images' in configuration 'linux-x86-zero-release'
> $

Yes, I indeed went too far with JDK-8351149. I will run some testing and will let you know soon!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28406#issuecomment-3569595094

From phubner at openjdk.org  Mon Nov 24 09:03:20 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 24 Nov 2025 09:03:20 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v2]
In-Reply-To: <8a-zXXvD21lIjPgL6TD9yEHVCK6feOa5-BrQMEcx820=.49a8037e-57d4-4e38-8f83-5221cc3bda57@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <IaZ_fgdcPder2qpk0StmyaGLCKAAlsyZdF5zHVDkM54=.d7ae561b-0cc3-4548-96fc-5c007b7af54e@github.com>
 <8a-zXXvD21lIjPgL6TD9yEHVCK6feOa5-BrQMEcx820=.49a8037e-57d4-4e38-8f83-5221cc3bda57@github.com>
Message-ID: <pmYh4FZhTF8Lf5r_5d_vH9_hPa9uZ51mOG16r8zRldk=.16c70a1e-d823-43d0-b9a1-d298aea48e5f@github.com>

On Mon, 24 Nov 2025 01:39:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Paul H?bner 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 four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8368551
>>  - Update doc.
>>  - Overhaul some core messages again.
>>  - Better posix coredump messages.
>
> src/hotspot/os/posix/os_posix.cpp line 129:
> 
>> 127:     } else if (core_path[0] == '"') { // redirect to user process
>> 128:       if (check_only) {
>> 129:         buf.print("core dumps are further processed the following: ");
> 
> Suggestion:
> 
>         buf.print("core dumps are further processed by the following: ");
> 
> or, given these processors are often disabled even if stored in the pattern:
> 
>         buf.print("core dumps may be further processed by the following: ");

I think the second suggestion would be more representative, I'll go ahead and add it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28174#discussion_r2555248492

From phubner at openjdk.org  Mon Nov 24 09:22:46 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Mon, 24 Nov 2025 09:22:46 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v3]
In-Reply-To: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
Message-ID: <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>

> Hi all,
> 
> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
> 
> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> 
> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
> 
> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # CreateCoredumpOnCrash turned off, no core file dumped
> 
> **Scenario 2: `get_core_path` errors**
> 
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: core.2618391 (may not exist)
> 
> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps are further processed the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.2620900)
> 
> **Scenario 4: the resource limit for core dumps could not be determined**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>> #
> 
> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>> Java HotSpot(TM) 64-Bit Server VM warni...

Paul H?bner 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:

 - Merge branch 'master' into JDK-8368551
 - Reviewer suggestions.
 - Merge branch 'master' into JDK-8368551
 - Update doc.
 - Overhaul some core messages again.
 - Better posix coredump messages.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28174/files
  - new: https://git.openjdk.org/jdk/pull/28174/files/f8fe78a2..3306d0de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28174&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28174&range=01-02

  Stats: 2385 lines in 71 files changed: 1625 ins; 391 del; 369 mod
  Patch: https://git.openjdk.org/jdk/pull/28174.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28174/head:pull/28174

PR: https://git.openjdk.org/jdk/pull/28174

From sspitsyn at openjdk.org  Mon Nov 24 10:24:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 24 Nov 2025 10:24:17 GMT
Subject: RFR: 8366659: ObjectMonitor::wait() can deadlock with a suspension
 request [v17]
In-Reply-To: <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
References: <UdMfEVulz3g2EUEIWECJ-Fz1muO78QqASbxEbaJcnT8=.3594df7e-92db-40cc-b6bc-e453b2fe6729@github.com>
 <r57F4E1a-LGSnOuAWA8sDkyPjCX2eQ-G829wfTIES-E=.4ea342ac-0a80-4c81-a9f5-659838f578ff@github.com>
 <1IG8jMnDDdRMkB8jSwlkmKv3RgOxry32boypwj5YT60=.fca53e75-4e30-4448-872a-8bec61076c43@github.com>
 <viB4OM2TleMyNVc1Cy4JxUAQxCHNlALcwZHWhip4dJQ=.9d6d5368-9ecf-467d-962e-7889de96c03a@github.com>
 <DOlRuuDs4XqrOiOWsWGBaH-_MgoQRtwXO3qgPNoxhaA=.c87e3b91-27e3-41bc-9fc0-6a6a7c9e13b3@github.com>
Message-ID: <bjrf0R5x_-JR_SdTJ2jgCnecDktYX3EgPU2PYTdrpSs=.abff2290-0fad-4aba-871a-efd9f99d15fb@github.com>

On Fri, 21 Nov 2025 11:38:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Thanks @sspitsyn for diving into the issue. 
>> 
>> With that definition of the deadlock and suspension logic I agree that it might not be a problem at all. With this being said, is the existing test `SuspendWithObjectMonitorWait` demonstrating a real-world scenario? @dcubed-ojdk, what do you think?
>
>> is the existing test SuspendWithObjectMonitorWait demonstrating a real-world scenario?
> 
> It does not look as such. There could be some motivation to write it however, e.g. checking some invariants. At least, it seems this test does not enforce any strict rules on the OM implementation and JVMTI events + suspend/resume. :)
> New tests do not allow for OM implementation to put `MonitorWaited` event notification at a right spot. Otherwise, I would not object against them.

> @sspitsyn so your position is that it is okay for suspension to cause something to break as long as resuming the suspended thread then fixes things? Does it matter how much time passes?

Suspend/Resume is a debugging feature and normally used in a debugging session and expected to cause a slow down. 
Also, it is known to be somewhat risky to use. So, my answer is yes. Slow down time does not matter much as it depends on a suspension time.

> We have had a lot of discussion about this outside the PR and some of us at least feel there is a distinction between suspending a thread that clearly holds an application level resource (like a monitor) which then prevents other threads from continuing, versus suspending a thread holding a VM internal "resource" that prevents other threads from continuing.

Agreed

> The design of JVM TI thread suspension actively tries to minimise the ability to hold any internal VM resource whilst suspended, and the current problem seems a variant of that. If we suspend a thread that has not yet acquired a monitor, and inspection of the monitor would show it is not owned, then it seems a bug if other threads trying to acquire that monitor can not make progress.

You, most likely right that the current problem is a variant of that. But I disagree to qualify this issue as a deadlock.
The thread was picked as a successor and then suspended. It feels like it has to be qualified same as a thread owns the monitor and suspended. The issue is that the OM real state and the JVMTI state bits do to reflect this.
I feel that changing the order of JVMTI OM events and giving up the symmetry between `timed-wait` and `notified-wait` is risky and may cause more problems than this bug is trying to solve. I'm thinking if there is a way the tread could give up
being the OM successor.

> Agreed the tests are completely artificial but there is no way to test this other than to do that.

Agree with this. But the deadlock is in the new tests, not in the OM implementation. And yes, constructing a deadlock was needed to demonstrate the problem. It is confusing. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27040#issuecomment-3569971399

From adinn at openjdk.org  Mon Nov 24 10:33:30 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 24 Nov 2025 10:33:30 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <RqmQ9_UJpI5Wj4Axl1XwQm5S9vE09Zs3q0XYNvdGmP0=.92f71df8-6069-418a-bf5f-cf468ab6e617@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
 <RqmQ9_UJpI5Wj4Axl1XwQm5S9vE09Zs3q0XYNvdGmP0=.92f71df8-6069-418a-bf5f-cf468ab6e617@github.com>
Message-ID: <NSQttx89qZk8QWFFxQDWGJs026b_otfYokwQDuptyYw=.5ea4b608-135c-4bd7-a012-f9a0a62784cd@github.com>

On Fri, 21 Nov 2025 18:53:17 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/hotspot/share/cds/aotMetaspace.cpp line 1062:
>> 
>>> 1060: bool AOTMetaspace::preimage_static_archive_dumped() {
>>> 1061:   assert(CDSConfig::is_dumping_preimage_static_archive(), "Required");
>>> 1062:   return _preimage_static_archive_dumped == 1;
>> 
>> Should it be  AtomicAccess::load(&_preimage_static_archive_dumped) here?
>
> Andrew brought this up also; I'll add but should it be AtomicAccess::load or AtomicAccess::load_acquire?

Just in case this might be called from a different thread to the one which is executing the `cmpxchg` you should really be using `AtomicAccess::load_acquire(&_preimage_static_archive_dumped)` here
You also need acquire-release semantics for the comparison below which you get as the default from your current use of `cmpxchg` below.

    if (AtomicAccess::cmpxchg(&_preimage_static_archive_dumped, 0, 1) != 0) {

Depending on the implementation that might be more heavyweight than you really need. e.g. given that the change is idempotent you could rely on a bare `xchg` with acq_rel semantics

    if (AtomicAccess::xchg(&_preimage_static_archive_dumped, 1, atomic_memory_order::memory_order_acq_rel) != 0) {

However, it's not going to matter very much since these are low-frequency operations.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2555662830

From shade at openjdk.org  Mon Nov 24 11:50:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Nov 2025 11:50:03 GMT
Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored
 after JDK-8322420 [v2]
In-Reply-To: <OaxCDljvO6iWBaGrBb2H6nXuE8vL1BDQLchtDzKeii8=.530e62c6-d0d6-4bae-a939-5d6a73b99951@github.com>
References: <AbutM4LlEmbwif872EpA_260YZQ2F2oOK5ysrDsNzqU=.3c0d7c22-7be4-4f5e-95b1-afd61a39d228@github.com>
 <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com>
 <OaxCDljvO6iWBaGrBb2H6nXuE8vL1BDQLchtDzKeii8=.530e62c6-d0d6-4bae-a939-5d6a73b99951@github.com>
Message-ID: <bO20387mrpOxLCZuy4CHPwbe-QWFfSmqvA-Db5ifrJk=.cd315e73-5a9b-476b-b980-0745716be764@github.com>

On Thu, 30 Oct 2025 19:08:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Also no need to touch the other getter
>>  - Whitespace
>
> Thank you both!

> Hi @shipilev , are you guys going to port this to jdk21u as per some of the comments? We'd be most thankful!

Yes. My original plan was to pull it into 25u and 21u ASAP. But it proves to be hairy to backport cleanly, as there were several prior changes in related code, which risks destabilizing this whole thing. So, it will unfortunately come slowly.

We took the calculated risk with Corretto [21.0.9.11.1](https://github.com/corretto/corretto-21/releases/tag/21.0.9.11.1) and [25.0.1.9.1](https://github.com/corretto/corretto-25/releases/tag/25.0.1.9.1), where we pulled related patches along with this fix. It would help if you could test those and see if magic smoke comes out of it :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3570403158

From jsjolen at openjdk.org  Mon Nov 24 12:14:54 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Nov 2025 12:14:54 GMT
Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next
In-Reply-To: <nCSdjRi9SqcR9RThn_F5DmK7peCliid5ZRXL2joRgQk=.8b72311c-435c-488b-ae5c-bebf241dd7b2@github.com>
References: <nCSdjRi9SqcR9RThn_F5DmK7peCliid5ZRXL2joRgQk=.8b72311c-435c-488b-ae5c-bebf241dd7b2@github.com>
Message-ID: <6rfYtUK0hkMzbwcOkZ5GaBBF6H2k2lQHQma060M19L8=.ede164b9-ef91-4b04-b6a9-38387c833eff@github.com>

On Mon, 10 Nov 2025 21:18:23 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early.
> 
> Test: tier1

Please add a unit test that shows how this change fixes the bug.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28225#pullrequestreview-3500082292

From jsikstro at openjdk.org  Mon Nov 24 12:59:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 24 Nov 2025 12:59:55 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v6]
In-Reply-To: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
Message-ID: <iHH-DqUHKu_IShfM7SYTP40DebszVMvpuHu9vh9Lg9c=.2b874330-80a6-44f9-9d9f-57a01c36f320@github.com>

> Hello,
> 
> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
> 
> Testing:
> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
> * Running through Oracle's tier1-2

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8371701_numa_affinity_threads
 - Offline review feedback from Axel
 - Harden comment around user configuration
 - Remove comparison
 - Change return type of numa_set_thread_affinity to void
 - 8371701: Add ability to set NUMA-affinity for threads

-------------

Changes: https://git.openjdk.org/jdk/pull/28261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28261&range=05
  Stats: 103 lines in 6 files changed: 103 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28261/head:pull/28261

PR: https://git.openjdk.org/jdk/pull/28261

From aboldtch at openjdk.org  Mon Nov 24 12:59:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 24 Nov 2025 12:59:56 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v6]
In-Reply-To: <iHH-DqUHKu_IShfM7SYTP40DebszVMvpuHu9vh9Lg9c=.2b874330-80a6-44f9-9d9f-57a01c36f320@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <iHH-DqUHKu_IShfM7SYTP40DebszVMvpuHu9vh9Lg9c=.2b874330-80a6-44f9-9d9f-57a01c36f320@github.com>
Message-ID: <nORmqjVFmjYHuTVnaOfbZ9leo7nkJb2Z6ztVgcSjcig=.7139cd20-2566-4f2c-9e53-6a4eb0b32698@github.com>

On Mon, 24 Nov 2025 12:55:35 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
>> 
>> Testing:
>> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
>> * Running through Oracle's tier1-2
>
> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8371701_numa_affinity_threads
>  - Offline review feedback from Axel
>  - Harden comment around user configuration
>  - Remove comparison
>  - Change return type of numa_set_thread_affinity to void
>  - 8371701: Add ability to set NUMA-affinity for threads

Marked as reviewed by aboldtch (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28261#pullrequestreview-3500243904

From dholmes at openjdk.org  Mon Nov 24 13:24:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Nov 2025 13:24:49 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v3]
In-Reply-To: <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>
Message-ID: <W9mw7aHTeK-9DUpzoWGurgzPb46EZjJruexmHaY0YvM=.df5469e6-7eab-4b30-afc4-418c981764a4@github.com>

On Mon, 24 Nov 2025 09:22:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>> 
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.2618391 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be further processed by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> # [...]
>>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> #
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateC...
>
> Paul H?bner 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:
> 
>  - Merge branch 'master' into JDK-8368551
>  - Reviewer suggestions.
>  - Merge branch 'master' into JDK-8368551
>  - Update doc.
>  - Overhaul some core messages again.
>  - Better posix coredump messages.

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28174#pullrequestreview-3500367546

From jsikstro at openjdk.org  Mon Nov 24 13:44:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 24 Nov 2025 13:44:04 GMT
Subject: RFR: 8371701: Add ability to set NUMA-affinity for threads [v3]
In-Reply-To: <SiZPx54oo55IpOPpcsfUM7IYkZYZleUag1-CfWGdIcM=.f3d38c6e-3dd6-41f4-8bca-1138eaa01b74@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
 <1AfMFywOkWMRplle12iyad4OQuufA72Bp9cxYpBb8Mo=.43ed792d-75d8-4a94-b1e0-00b45d037987@github.com>
 <SiZPx54oo55IpOPpcsfUM7IYkZYZleUag1-CfWGdIcM=.f3d38c6e-3dd6-41f4-8bca-1138eaa01b74@github.com>
Message-ID: <B5ID2SPGglXf8LUkKuIyfbG-XyrFWDD-i4wX2uGhkjA=.2e0e0e9a-f38a-4020-9cac-1b0bcc33a9ce@github.com>

On Thu, 13 Nov 2025 13:45:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove comparison
>
> Marked as reviewed by ayang (Reviewer).

Thank you for the reviews!?@albertnetymk @xmas92

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28261#issuecomment-3570842583

From jsikstro at openjdk.org  Mon Nov 24 13:44:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 24 Nov 2025 13:44:06 GMT
Subject: Integrated: 8371701: Add ability to set NUMA-affinity for threads
In-Reply-To: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
References: <CdQAQ2Gi7snnIZd7grY9hMT4-6mdQ2qro7ksd00FuZw=.c6328073-4320-494e-91ea-3e8a2a010380@github.com>
Message-ID: <5WqDZF2VzZFgtin1-5RudEqow2CXvnGnwo7k5nObmQY=.3147b5e8-93dd-45ae-a1c2-159f6e20d237@github.com>

On Wed, 12 Nov 2025 10:22:39 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This PR adds support for setting the affinity of threads to run on CPUs associated with specific NUMA nodes on Linux. Support for this is needed for [JDK-8371702](https://bugs.openjdk.org/browse/JDK-8371702) to improve performance in the Relocation Phase of ZGC on a NUMA machine.
> 
> Testing:
> * I've run significant performance testing locally on a NUMA machine and performed functional testing to see that the affinity is actually changed. Affinity of a thread can be inspected on Linux using `taskset -cp <tid>`.
> * Running through Oracle's tier1-2

This pull request has now been integrated.

Changeset: 0a963b61
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a963b612d0fcbfe002340098341862096650945
Stats:     103 lines in 6 files changed: 103 ins; 0 del; 0 mod

8371701: Add ability to set NUMA-affinity for threads

Reviewed-by: aboldtch, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/28261

From coleenp at openjdk.org  Mon Nov 24 14:03:08 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Nov 2025 14:03:08 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <PwGyMwhe8hhtv3sAQyqoa2WESL_7yIAT2A4TsiyYh4k=.fcea8a81-9476-44f8-b413-7279ad31a398@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
 <X9wJ3Its78BTbwHOWKZNKo-zQHatArJ7IpWiUlAjdNg=.1ea93714-56a0-44f3-8281-a3def5872caa@github.com>
 <PwGyMwhe8hhtv3sAQyqoa2WESL_7yIAT2A4TsiyYh4k=.fcea8a81-9476-44f8-b413-7279ad31a398@github.com>
Message-ID: <xZ5vAMTZWiWsIpNc_OfFFFOmDjNeG278VlkxIJYKWDc=.5d92088e-4161-427e-b8d0-34aeac9d72ab@github.com>

On Sun, 23 Nov 2025 21:23:12 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> If I use that, I lose the ability to assert that the new entry was created and not already found, which I really want.
>
> `put_when_absent` means "put it in the table when I know it's absent". It already has the assert that you want.
> 
> https://github.com/openjdk/jdk/blob/e18e95ed11c1df7eeb162c2303f027564ed6f6aa/src/hotspot/share/utilities/hashTable.hpp#L149-L152

I see.  Thanks for pointing it out. I've changed both HashTable::put() to put_when_absent then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2556395826

From ayang at openjdk.org  Mon Nov 24 14:29:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 24 Nov 2025 14:29:41 GMT
Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next
 [v2]
In-Reply-To: <nCSdjRi9SqcR9RThn_F5DmK7peCliid5ZRXL2joRgQk=.8b72311c-435c-488b-ae5c-bebf241dd7b2@github.com>
References: <nCSdjRi9SqcR9RThn_F5DmK7peCliid5ZRXL2joRgQk=.8b72311c-435c-488b-ae5c-bebf241dd7b2@github.com>
Message-ID: <NZDw7Ao9GFDHtxLbW7MTsQuWTrW-azjac9e318dQLVk=.fd95754e-e6b5-4068-bbd3-0658fe1f4b40@github.com>

> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early.
> 
> The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path.
> 
> 
> Test: tier1

Albert Mingkun Yang 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 four additional commits since the last revision:

 - copyright-header
 - review
 - Merge branch 'master' into smap-parser
 - smap-parser

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28225/files
  - new: https://git.openjdk.org/jdk/pull/28225/files/f79c046f..c179ccd5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28225&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28225&range=00-01

  Stats: 73896 lines in 1020 files changed: 49098 ins; 18058 del; 6740 mod
  Patch: https://git.openjdk.org/jdk/pull/28225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28225/head:pull/28225

PR: https://git.openjdk.org/jdk/pull/28225

From jsjolen at openjdk.org  Mon Nov 24 15:13:03 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Nov 2025 15:13:03 GMT
Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next
 [v2]
In-Reply-To: <NZDw7Ao9GFDHtxLbW7MTsQuWTrW-azjac9e318dQLVk=.fd95754e-e6b5-4068-bbd3-0658fe1f4b40@github.com>
References: <nCSdjRi9SqcR9RThn_F5DmK7peCliid5ZRXL2joRgQk=.8b72311c-435c-488b-ae5c-bebf241dd7b2@github.com>
 <NZDw7Ao9GFDHtxLbW7MTsQuWTrW-azjac9e318dQLVk=.fd95754e-e6b5-4068-bbd3-0658fe1f4b40@github.com>
Message-ID: <KNxOGPGNzN8cUOTMoAryKpSNRTZzgZEDrHMNebF_pS4=.47a4baf3-4bde-4e0d-a962-e42ba7055cb9@github.com>

On Mon, 24 Nov 2025 14:29:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early.
>> 
>> The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path.
>> 
>> 
>> Test: tier1
>
> Albert Mingkun Yang 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 four additional commits since the last revision:
> 
>  - copyright-header
>  - review
>  - Merge branch 'master' into smap-parser
>  - smap-parser

Thank you, LGTM!

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28225#pullrequestreview-3500895873

From duke at openjdk.org  Mon Nov 24 15:58:32 2025
From: duke at openjdk.org (David Latorre)
Date: Mon, 24 Nov 2025 15:58:32 GMT
Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored
 after JDK-8322420 [v2]
In-Reply-To: <OaxCDljvO6iWBaGrBb2H6nXuE8vL1BDQLchtDzKeii8=.530e62c6-d0d6-4bae-a939-5d6a73b99951@github.com>
References: <AbutM4LlEmbwif872EpA_260YZQ2F2oOK5ysrDsNzqU=.3c0d7c22-7be4-4f5e-95b1-afd61a39d228@github.com>
 <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com>
 <OaxCDljvO6iWBaGrBb2H6nXuE8vL1BDQLchtDzKeii8=.530e62c6-d0d6-4bae-a939-5d6a73b99951@github.com>
Message-ID: <S5SeNH-JBD4PmClVHiDbMIQMT8mkVwjE3uVLghH3ItY=.9b6ec881-b025-4ab5-b127-b3f17fb191e5@github.com>

On Thu, 30 Oct 2025 19:08:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Also no need to touch the other getter
>>  - Whitespace
>
> Thank you both!

Hi @shipilev , are you guys going to port this to jdk21u as per some of the comments? We'd be most thankful!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3570145010

From aseoane at openjdk.org  Mon Nov 24 16:01:55 2025
From: aseoane at openjdk.org (Anton Seoane Ampudia)
Date: Mon, 24 Nov 2025 16:01:55 GMT
Subject: RFR: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
Message-ID: <QwPztavjFKrx-swU2uFAh_qHHo1jU9jx-egnChdFuGM=.bdf77da5-81fb-4402-8136-87cc0734e3a2@github.com>

On Thu, 20 Nov 2025 01:27:01 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.
> 
> Reverted changes to:
>  -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries
> 
> Testing (in Ubuntu 26.04 i386 chroot):
> 
> $ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
> ...
> $ make images
> Building target 'images' in configuration 'linux-x86-zero-release'
> Warning: No SCM configuration present and no .src-rev
> Updating images/sec-bin.zip
> Finished building target 'images' in configuration 'linux-x86-zero-release'
> $

Looks good!

-------------

Marked as reviewed by aseoane (Author).

PR Review: https://git.openjdk.org/jdk/pull/28406#pullrequestreview-3501127832

From shade at openjdk.org  Mon Nov 24 16:03:15 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 24 Nov 2025 16:03:15 GMT
Subject: RFR: 8370572: Cgroups hierarchical memory limit is not honored
 after JDK-8322420 [v2]
In-Reply-To: <OaxCDljvO6iWBaGrBb2H6nXuE8vL1BDQLchtDzKeii8=.530e62c6-d0d6-4bae-a939-5d6a73b99951@github.com>
References: <AbutM4LlEmbwif872EpA_260YZQ2F2oOK5ysrDsNzqU=.3c0d7c22-7be4-4f5e-95b1-afd61a39d228@github.com>
 <1OxR2q8sxrU7nfU-5fx_kGyweNyx-vWRRCzeivKPB50=.b2efc6b5-4126-4782-bb2d-43c903ba110f@github.com>
 <OaxCDljvO6iWBaGrBb2H6nXuE8vL1BDQLchtDzKeii8=.530e62c6-d0d6-4bae-a939-5d6a73b99951@github.com>
Message-ID: <XpwZegHLJLBwx_COzW61_JMxEWGVfrxvmkYB-G9axpk=.98feabe6-9928-4d87-b7cc-856acff30e90@github.com>

On Thu, 30 Oct 2025 19:08:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Also no need to touch the other getter
>>  - Whitespace
>
> Thank you both!

> Hi @shipilev , are you guys going to port this to jdk21u as per some of the comments? We'd be most thankful!

Yes. See the updates in [pinned comment here](https://bugs.openjdk.org/browse/JDK-8370572?focusedId=14835952#comment-14835952).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28006#issuecomment-3571538759

From vpetko at openjdk.org  Mon Nov 24 16:04:14 2025
From: vpetko at openjdk.org (Vladimir Petko)
Date: Mon, 24 Nov 2025 16:04:14 GMT
Subject: Integrated: 8370978: Zero JVM fails to build on i386 after JDK-8351149
In-Reply-To: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
References: <uqFA2cDL48CDPwwGkE7XKSr5rT9xOW6fDqzvpbjQqlk=.f56cacd0-369e-4c0c-92e2-a6176edecb6c@github.com>
Message-ID: <O_vVaAWgH_VU0hzQVfWg_d2ymya8Zfc3u6at1DXLR4M=.a00accb4-2bef-4c0d-add8-d45b6395d687@github.com>

On Thu, 20 Nov 2025 01:27:01 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> This PR partially reverts  JDK-8351149 to restore zero build on 32 bit platforms.
> 
> Reverted changes to:
>  -` os::dll_load`, `os::Linux::dlopen_helper`  - the functions  required to load the shared libraries
> 
> Testing (in Ubuntu 26.04 i386 chroot):
> 
> $ sh configure --with-jvm-variants=zero --disable-precompiled-headers  --with-jtreg=/home/vladimirp/git/jtreg/build/images/jtreg --disable-warnings-as-errors
> ...
> $ make images
> Building target 'images' in configuration 'linux-x86-zero-release'
> Warning: No SCM configuration present and no .src-rev
> Updating images/sec-bin.zip
> Finished building target 'images' in configuration 'linux-x86-zero-release'
> $

This pull request has now been integrated.

Changeset: 67b57f4f
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67b57f4f758f2fea647a3b6a68c0372a8f9e121b
Stats:     12 lines in 1 file changed: 10 ins; 0 del; 2 mod

8370978: Zero JVM fails to build on i386 after JDK-8351149

Reviewed-by: shade, aseoane

-------------

PR: https://git.openjdk.org/jdk/pull/28406

From coleenp at openjdk.org  Mon Nov 24 18:40:22 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 24 Nov 2025 18:40:22 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
Message-ID: <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>

> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
> 
> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
> 
> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
> 
> Tested with submitted reproducer and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Use put_when_absent and add an assert that the message is the same.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28438/files
  - new: https://git.openjdk.org/jdk/pull/28438/files/c959cfe7..a0c53929

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=03-04

  Stats: 5 lines in 2 files changed: 1 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28438/head:pull/28438

PR: https://git.openjdk.org/jdk/pull/28438

From jsjolen at openjdk.org  Mon Nov 24 19:35:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Nov 2025 19:35:56 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
Message-ID: <HyEQ8ij1XLyrImL5EOoHePrI3yrfZplRewTApqxVr5g=.d8d55b2d-c058-4d0e-877f-808692b3309a@github.com>

On Mon, 24 Nov 2025 18:40:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use put_when_absent and add an assert that the message is the same.

The bug fix seems good, but it seems like this code leaks?

src/hotspot/share/classfile/resolutionErrors.cpp line 76:

> 74:   ResolutionErrorKey key(pool(), cp_index);
> 75:   ResolutionErrorEntry *entry = new ResolutionErrorEntry(error, message, cause, cause_msg);
> 76:   _resolution_error_table->put(key, entry);

This is surely leaking the ResolutionErrorEntry if the key is already present?

src/hotspot/share/classfile/resolutionErrors.cpp line 88:

> 86:   ResolutionErrorKey key(pool(), cp_index);
> 87:   ResolutionErrorEntry *entry = new ResolutionErrorEntry(message);
> 88:   _resolution_error_table->put(key, entry);

Same leak here

-------------

PR Review: https://git.openjdk.org/jdk/pull/28438#pullrequestreview-3501943559
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2557489835
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2557490448

From jsjolen at openjdk.org  Mon Nov 24 19:35:57 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Nov 2025 19:35:57 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <HyEQ8ij1XLyrImL5EOoHePrI3yrfZplRewTApqxVr5g=.d8d55b2d-c058-4d0e-877f-808692b3309a@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <HyEQ8ij1XLyrImL5EOoHePrI3yrfZplRewTApqxVr5g=.d8d55b2d-c058-4d0e-877f-808692b3309a@github.com>
Message-ID: <GVJWQ8hvpKb24778_jnrldGgpJz8UtcOimIjAgbY1tQ=.ebd4891b-4f8d-4103-9fa1-4cf1dd158ab3@github.com>

On Mon, 24 Nov 2025 19:31:42 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use put_when_absent and add an assert that the message is the same.
>
> src/hotspot/share/classfile/resolutionErrors.cpp line 76:
> 
>> 74:   ResolutionErrorKey key(pool(), cp_index);
>> 75:   ResolutionErrorEntry *entry = new ResolutionErrorEntry(error, message, cause, cause_msg);
>> 76:   _resolution_error_table->put(key, entry);
> 
> This is surely leaking the ResolutionErrorEntry if the key is already present?

This was meant to comment your new code, not the old code... Same with the other comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2557497236

From jsjolen at openjdk.org  Mon Nov 24 20:38:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Nov 2025 20:38:07 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
Message-ID: <EnZFGD0z6L2ah7r5-epxHkKqQJg5cVQN75bP59O77fs=.6e2e8159-e235-400d-9d56-6e0fb927242b@github.com>

On Mon, 24 Nov 2025 18:40:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use put_when_absent and add an assert that the message is the same.

Marked as reviewed by jsjolen (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28438#pullrequestreview-3502146577

From jsjolen at openjdk.org  Mon Nov 24 20:38:09 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 24 Nov 2025 20:38:09 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <GVJWQ8hvpKb24778_jnrldGgpJz8UtcOimIjAgbY1tQ=.ebd4891b-4f8d-4103-9fa1-4cf1dd158ab3@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <HyEQ8ij1XLyrImL5EOoHePrI3yrfZplRewTApqxVr5g=.d8d55b2d-c058-4d0e-877f-808692b3309a@github.com>
 <GVJWQ8hvpKb24778_jnrldGgpJz8UtcOimIjAgbY1tQ=.ebd4891b-4f8d-4103-9fa1-4cf1dd158ab3@github.com>
Message-ID: <RNDQHs781HFyKW1yMEG5Lr8xXUviHsgf9oukAqqxSy4=.90abda25-86d0-4ffc-9a80-80bed1479e5b@github.com>

On Mon, 24 Nov 2025 19:33:25 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/classfile/resolutionErrors.cpp line 76:
>> 
>>> 74:   ResolutionErrorKey key(pool(), cp_index);
>>> 75:   ResolutionErrorEntry *entry = new ResolutionErrorEntry(error, message, cause, cause_msg);
>>> 76:   _resolution_error_table->put(key, entry);
>> 
>> This is surely leaking the ResolutionErrorEntry if the key is already present?
>
> This was meant to comment your new code, not the old code... Same with the other comment.

My bad, `put_when_absent` asserts that entry is absent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2557651118

From macarte at openjdk.org  Tue Nov 25 00:58:06 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 00:58:06 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v6]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <PrfhvGt_sEZgS7ml8X2iOb7LJKAFP-zIMAeXk6AJXeg=.354be362-8be8-404b-a45a-452436de0969@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
> - Recording has already ended.
> - Error: Failed to end recording.
> - Recording ended successfully.
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully.
> - Recording has already ended.
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Added acquire_load and improved tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/f1f5d77d..2223870c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=04-05

  Stats: 30 lines in 3 files changed: 24 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965

PR: https://git.openjdk.org/jdk/pull/27965

From macarte at openjdk.org  Tue Nov 25 00:58:12 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 00:58:12 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v5]
In-Reply-To: <wGhYdujXMnJXPDNRXQsVdoWeJUHLBUQ_pmHUErcrj2k=.a5621030-3bfa-48de-b992-20890be5de24@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <jL_Fmq-ooAMMRn9Fl5PQ37z7zH4kpQSeiCW4MphNCQ0=.aec5842c-07e9-4cd9-b71c-b04799d388ed@github.com>
 <iC9FsM9cQjhIVHMrMNeMEvn1gh7xOBIfnf62cvm7BwM=.44b7e1bf-dda6-42c2-a8f1-5582f24acf12@github.com>
 <wGhYdujXMnJXPDNRXQsVdoWeJUHLBUQ_pmHUErcrj2k=.a5621030-3bfa-48de-b992-20890be5de24@github.com>
Message-ID: <2faJMusAYCjby-CJDGEQOkBywiV8yw-pGNqYzlJy2Mg=.48cebdc2-9f95-4e59-a228-e4e0a803fd40@github.com>

On Fri, 21 Nov 2025 18:43:44 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 31:
>> 
>>> 29:  * @summary Sanity test for Jcmd AOT.end_recording command
>>> 30:  * @library /test/lib
>>> 31:  * @build JcmdAOTEndRecordingTest
>> 
>> No need to build test explicitly, jtreg does it by itself.
>
> Thank you, I did not know that (copied another test as a template) - I've removed the build step in the header of both tests

I tried this and it seemed to work until I modified the test then the app.jar failed to build.

>> test/hotspot/jtreg/runtime/cds/appcds/aotCache/JcmdAOTEndRecordingTest.java line 57:
>> 
>>> 55:             try {
>>> 56:                 OutputAnalyzer output = ProcessTools.executeProcess(jcmd.getCommand());
>>> 57:                 output.shouldContain("AOT.end_recording is unsupported");
>> 
>> A little bit confused.  The check doesn't match test description.
>
> This test uses Lingered apps (enabling the jcmd connection), however the test framework here doesn't support creating the AOT cache - so I simply check that the connection works and the diagnostic command returns the expected value when you aren't recording a cache
> 
> I'm trying to create an additional test that allows jcmd to end training on an AOT recording, but there's some issues merging the jcmd test support and the aot test support;  I will make it clearer in this test about this limitation

Updated the test now, it runs twice, once in training mode and once not.  And checks the appropriate response from the diagnostic command

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2558149696
PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2558153818

From macarte at openjdk.org  Tue Nov 25 01:01:19 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 25 Nov 2025 01:01:19 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
> - Recording has already ended.
> - Error: Failed to end recording.
> - Recording ended successfully.
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully.
> - Recording has already ended.
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Check exit value in tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27965/files
  - new: https://git.openjdk.org/jdk/pull/27965/files/2223870c..dae85272

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27965&range=05-06

  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27965/head:pull/27965

PR: https://git.openjdk.org/jdk/pull/27965

From dholmes at openjdk.org  Tue Nov 25 01:28:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Nov 2025 01:28:47 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
Message-ID: <8fzexwHr8TfZixYCA8ZCbEqnG9vJwqELVGfWiRFYxdU=.0251ecd3-057e-46f2-b545-cdd52dfe2549@github.com>

On Mon, 24 Nov 2025 18:40:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use put_when_absent and add an assert that the message is the same.

Fix looks good, but an additional check requested. Thanks

src/hotspot/share/classfile/systemDictionary.cpp line 1877:

> 1875:       // only reach here under the same error condition, so we can ignore the potential race with setting
> 1876:       // the message, and set it again.
> 1877:       assert(entry->nest_host_error() == nullptr || strcmp(entry->nest_host_error(), message) == 0, "should be the same message");

Rather than overwrite the message I would keep the existing null check and maintain three cases:
1. No entry so add new one with message
2. Existing entry with no-message, so add it
3. Existing entry with message - just assert message is the same.

src/hotspot/share/classfile/systemDictionary.cpp line 1878:

> 1876:       assert(pool->resolved_klass_at(which) != nullptr, "klass is should be resolved if there is no entry");
> 1877:       ResolutionErrorTable::add_entry(pool, which, message);
> 1878:     }

Suggestion:

    } else if (entry == nullptr) {
      // Only add a new resolution error if one hasn't been found for this constant pool index. In this case,
      // resolution succeeded but there's an error in this nest host.
      assert(pool->resolved_klass_at(which) != nullptr, "klass is should be resolved if there is no entry");
      ResolutionErrorTable::add_entry(pool, which, message);
    } else {
      assert(strcmp(entry->nest_host_error(), message) == 0, "Different nest host error messages found: existing: %s, new %s", entry->nest_host_error(), message);
    }

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28438#pullrequestreview-3498002822
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2558214603
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2554325963

From dholmes at openjdk.org  Tue Nov 25 01:28:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 25 Nov 2025 01:28:48 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <RNDQHs781HFyKW1yMEG5Lr8xXUviHsgf9oukAqqxSy4=.90abda25-86d0-4ffc-9a80-80bed1479e5b@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <HyEQ8ij1XLyrImL5EOoHePrI3yrfZplRewTApqxVr5g=.d8d55b2d-c058-4d0e-877f-808692b3309a@github.com>
 <GVJWQ8hvpKb24778_jnrldGgpJz8UtcOimIjAgbY1tQ=.ebd4891b-4f8d-4103-9fa1-4cf1dd158ab3@github.com>
 <RNDQHs781HFyKW1yMEG5Lr8xXUviHsgf9oukAqqxSy4=.90abda25-86d0-4ffc-9a80-80bed1479e5b@github.com>
Message-ID: <hvJFdvFA8X97t4m9FEXLzoDeOZK-yPExWn3CWiLm-K4=.90327ad6-2792-4948-859b-325a5f1a1404@github.com>

On Mon, 24 Nov 2025 20:33:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> This was meant to comment your new code, not the old code... Same with the other comment.
>
> My bad, `put_when_absent` asserts that entry is absent.

That aside we are only calling `add_entry` when we have checked there is no existing entry.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2558218825

From azafari at openjdk.org  Tue Nov 25 09:51:40 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 25 Nov 2025 09:51:40 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v6]
In-Reply-To: <M6JyP0gIcJwY7naX0dKLc-Tj_EwGhQa5k4zPWSn4dPU=.f63c91c9-8acb-4d5a-b968-fc0cc4e7c5c9@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
 <GHakO5HS_bBpXH6DIvfkhMpclt0fbzOjImFFHoJyHYk=.b0ccd55b-ec2f-42ab-8189-b7493f1edd60@github.com>
 <M6JyP0gIcJwY7naX0dKLc-Tj_EwGhQa5k4zPWSn4dPU=.f63c91c9-8acb-4d5a-b968-fc0cc4e7c5c9@github.com>
Message-ID: <Z5c7emN0v6d364iVHrThGB7mGTJfmedMdVKKQwXlu-g=.c87c2351-06c4-40b0-a534-3df66cee1a16@github.com>

On Thu, 20 Nov 2025 13:01:45 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - fixes
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - master merge fix
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - after merge with 8366363.
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure
>
> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 271:
> 
>> 269:   inline const NativeCallStack* committed_call_stack() const         { return &_committed_stack; }
>> 270: 
>> 271:   bool is_valid() const { return base() != nullptr && size() != 0;}
> 
> The old structures had the base address and size by default initialised to 1. I think the new "invalid" values of 0 and 0 are more ergonomic, but I'm wondering, what's the reason we used 1 originally?

IIRC, they were used for debugging  and tracing some cases that happened during VMATree implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2559312713

From azafari at openjdk.org  Tue Nov 25 10:07:47 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 25 Nov 2025 10:07:47 GMT
Subject: RFR: 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions
 into one structure [v6]
In-Reply-To: <M6JyP0gIcJwY7naX0dKLc-Tj_EwGhQa5k4zPWSn4dPU=.f63c91c9-8acb-4d5a-b968-fc0cc4e7c5c9@github.com>
References: <VAXb2sqQHv-DZ2KOQIm01qJV2Q3Wqdb0erNFX5rVypk=.e710db06-c14f-4fa7-944f-e96a2e54fd64@github.com>
 <GHakO5HS_bBpXH6DIvfkhMpclt0fbzOjImFFHoJyHYk=.b0ccd55b-ec2f-42ab-8189-b7493f1edd60@github.com>
 <M6JyP0gIcJwY7naX0dKLc-Tj_EwGhQa5k4zPWSn4dPU=.f63c91c9-8acb-4d5a-b968-fc0cc4e7c5c9@github.com>
Message-ID: <qkyL9DIsIMQjXCdV1d5RusZ6_h_H8mU4NIa6BwN8DNU=.f23f761d-10e2-4f47-a8d7-2f7d16b06791@github.com>

On Thu, 20 Nov 2025 13:05:52 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - fixes
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - master merge fix
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - after merge with 8366363.
>>  - Merge remote-tracking branch 'origin/master' into _8366241_nmt_consolidate_structures
>>  - 8366241: NMT: Consolidate [Virtual/Committed/Reserved]Regions into one structure
>
> src/hotspot/share/nmt/virtualMemoryTracker.hpp line 217:
> 
>> 215:   }
>> 216: 
>> 217:   VirtualMemoryRegion(address addr, size_t size, const NativeCallStack& stack, bool committed) :
> 
> Correct me if I'm wrong but is this `committed` only ever true? And then we use the presence of this constructor parameter to decide whether we are creating a committed or a reserved region?
> 
> If so, at the very least we should assert that committed is true. But I think it would be nicer to make the constructor private and make some static factory methods akin to `VirtualMemoryRegion::committed` and `VirtualMemoryRegion::reserved`.

You are right. The `committed` is used here to distinguish signatures of the VMR constructor. 
`VMR(address, size_t, NativeCallStack)` without this parameter would have been resolved to `VMR(address, size_t, NCS, MemTag= mtNone)`. Actually it doesn't matter if the value of the parameter be true or false, the `bool` type does the work for us.
There is only one instance that uses this signature: `regionsTree.inline.hpp:41`.
Regarding your suggestion, we can provide a static method to build a Committed memory region and pass into it the required values. Something like:

VMR cmr;
VMR::create_cmr(addr, size, stack, cmr);// cmr is passed by ref and filled in

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27137#discussion_r2559371834

From kevinw at openjdk.org  Tue Nov 25 13:16:15 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 13:16:15 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <ClN6KLNjUKLfedhkfopFfCRowAHkgqJkI_xShcwaDDs=.6b6ee5ca-0a2b-4027-bba4-fb212293d4f9@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

test/hotspot/jtreg/runtime/cds/appcds/aotCache/DiagnosticCommandMBeanTest.java line 152:

> 150:                 System.out.println("Failed to stop recording");
> 151:             }
> 152:         } catch (MBeanException e) {

Can we catch Exception here generally, and print the stacktrace so we can see what happened if there are failures?

Then print the "Exception occurred!" so it's seen by the caller and the test fails.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27965#discussion_r2559943955

From kevinw at openjdk.org  Tue Nov 25 13:30:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Nov 2025 13:30:23 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <bZkoUANvHq2iBsBARB1HKX3qAbYHpB-3veq4R7H-zM8=.958c0dfb-7f07-469c-9bf2-66036ceab6c0@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

Looking good I think.

A possible general issue is that the AOT implementation of the dumping may write mesages on tty-> but they are not captured by the jcmd.  Not too much of an issue for a training run as presumably the app is being monitored by whoever asks for the endRecording() to happen.  I think the plan for now would be: should the jcmd fail, you check the app output for possibly more detail.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3575650962

From stuefe at openjdk.org  Tue Nov 25 14:25:32 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Nov 2025 14:25:32 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v24]
In-Reply-To: <-dePf4_Xx0lhAl-KTFEX3i4VAzFivobZ0Jo1vMY7zCc=.f4c0eb29-405b-4ee6-9246-090bf554dd9a@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <-dePf4_Xx0lhAl-KTFEX3i4VAzFivobZ0Jo1vMY7zCc=.f4c0eb29-405b-4ee6-9246-090bf554dd9a@github.com>
Message-ID: <w4InEOpE8v1P0CYYhLbkXPAeu8DOGGA-cyfBQcNZwRU=.b8356f7e-ab44-4d79-8726-7eceb8ba994d@github.com>

On Wed, 19 Nov 2025 10:48:35 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> NMT can detect malloc'd memory corruption using canary tests at header and footer of every memory region. This can only be done at free time of the memory where NMT checks the canaries and report error if they are not as expected.
>> In this PR, the canary parts also are poisoned using ASAN API to get notified whenever a read/write op is done. on the canary parts. `_size` member of the malloc header is also poisoned, since it is used for finding the footer address.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pragma fix

Hi @afshin-zafari , 

In general, I support the goal of this PR, but in its current form, it incurs too high a cost for the added complexity. 

The benefit this PR provides is that, with NMT enabled, we won't catch 1-2-byte overwriters at the end and up to 16-byte underwriters at the start of a block. Underwriters are very rare; overwriters are a lot more common. So, if someone overwrites by one or two bytes, today we only see it if the block is free'd. If someone overwrites three bytes, we already have protection. With your patch, we see also 1-2 byte overwriters.

But there is a straightforward workaround: just disable NMT. Then, the protection extends right to the borders of the user payload.

Considering that, the benefit of this PR is there, but it's not huge. Therefore, the complexity cost should be correspondingly low.

As I wrote before, I don't think poisoning and unpoisoning in this fine-grained fashion is the best approach. It often makes little sense. For example, in os::malloc we have at least one poison-unpoison-poison cycle, possibly more. It would be a lot simpler to do this carefully and only where it's needed:

- poison the malloc header and footer when we *hand out a malloc'ed block* to the user *at the end of*  `os::malloc` or `os::realloc`
- unpoison the header and footer *on the entry* to `os::realloc` and `os::free` to be able to read the MST marker.

That's it. No more poisoning should be needed.

NMT block integrity checks should simply not run for ASAN. They make zero sense. They check header corruptions, but who is going to corrupt the canary if the header is now protected by ASAN? In fact, we should not even need to initialize the canaries.

Basically, that means not calling either one of `check_block_integrity` or `is_valid_malloced_pointer` or `print_block_on_error` if ASAN is enabled. Resp. stubbing them out for ASAN. But I see only one call site that does this. Ideally, one would have a new define like "NMT_BLOCK_INTEGRITY_CHECKS", and guard the NMT integrity checks with that one, and switch it off for ASAN.

That means that a large part of this PR can be simplified. Many functions can stay as they are, and there should be no need for an RAII object like `AsanPoisoningHelper`. We should only have two poison calls for the header and footer, and two unpoison calls, none of which share the same extent, so RAII can't be used.

Other than that, there are many cosmetic changes in this PR, e.g., many accessor functions added. That is a matter of taste - they also create unnecessary noise. But I would prefer it if these cosmetics were done in a separate PR - I would really like to see only the functional changes in this PR.

src/hotspot/share/nmt/mallocHeader.hpp line 141:

> 139:   void asan_unpoison_self() const {
> 140:     AsanPoisoningHelper::unpoison_memory(this, sizeof(MallocHeader));
> 141:     AsanPoisoningHelper::unpoison_memory(footer_address(), sizeof(uint16_t));

Why not use the macros directly?

src/hotspot/share/nmt/mallocHeader.inline.hpp line 38:

> 36: 
> 37: inline MallocHeader::MallocHeader(size_t size, MemTag mem_tag, uint32_t mst_marker)
> 38:   : _size(size), _mst_marker(mst_marker), _mem_tag(mem_tag), _unused(0),

Why this initialization? It seems incidental to the goal of the PR.

src/hotspot/share/nmt/mallocTracker.cpp line 199:

> 197:   {
> 198:     const MallocHeader* header2 = MallocHeader::resolve_checked(memblock);
> 199:     AsanPoisoningHelper aph(header2, sizeof(MallocHeader));

Why is this needed? We just malloced, the header should be unpoisened.

src/hotspot/share/sanitizers/address.hpp line 85:

> 83: // General un/poisoning API are provided too.
> 84: class AsanPoisoningHelper {
> 85:   const void* _memory_region;

I meant pointer mutability:

Suggestion:

  const void* const _memory_region;


The object should be immutable. There is no need for it to be mutable; changing the address in-flight would be an error.

src/hotspot/share/sanitizers/address.hpp line 95:

> 93:     ASAN_POISON_MEMORY_REGION(_memory_region, _size);
> 94:   }
> 95:   static void poison_memory(const void* addr, const size_t size) {

Why are these functions needed? They don't seem to add anything to `ASAN_POISON_MEMORY_REGION` ?

Not only for complexity reduction, but also for "grep-ability" . The more aliasing of names one does, the more complex it gets to do simple searches quickly like "where do we unpoison memory?"

src/hotspot/share/sanitizers/address.hpp line 106:

> 104: 
> 105: class AsanPoisoningHelper {
> 106:  public:

For more brevity, this class can look like this:

struct AsanPoisoningHelper {
  AsanPoisoningHelper() = delete;
  AsanPoisoningHelper(const void* addr, const size_t size) {}
};

src/hotspot/share/sanitizers/address.hpp line 109:

> 107:   AsanPoisoningHelper() = delete;
> 108:   AsanPoisoningHelper(const void* addr, const size_t size) {}
> 109:   ~AsanPoisoningHelper() { }

destructor is not needed

src/hotspot/share/sanitizers/address.hpp line 111:

> 109:   ~AsanPoisoningHelper() { }
> 110:   static void poison_memory(const void* addr, const size_t size) { }
> 111:   static void unpoison_memory(const void* addr, size_t size) { }

Arguably not needed, see my remark above

-------------

PR Review: https://git.openjdk.org/jdk/pull/27685#pullrequestreview-3482227957
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2559974057
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2559975874
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2559962335
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2558658174
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2541647225
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2559498936
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2559496332
PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2559500304

From stuefe at openjdk.org  Tue Nov 25 14:25:35 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 25 Nov 2025 14:25:35 GMT
Subject: RFR: 8369393: NMT: poison the canaries of malloc header under ASAN
 build [v16]
In-Reply-To: <MK-U2bAlN9nBu6FDlkKyOyuEEsytOyEQ0sliGG3mihw=.c73277da-6006-4271-8660-22ead82a0c41@github.com>
References: <tv1fC01Pt5Nw8ql7bGOxF6gHozhnh7pUORGQ9jY5itQ=.0ce02705-1be5-46da-b28e-6111abaddff0@github.com>
 <DWvXEJ1vmq4z76zONCHQ2l6chiAK2B86GeqgkScQSAU=.1e7cb038-ecd0-420a-b814-ab268b0fde26@github.com>
 <fFD5QFu8N2bMfc1JVDm4Xx2hG3RCjMsxE3gTkm1heQQ=.0d37ce54-62a5-4b5d-a464-db2f29432293@github.com>
 <MK-U2bAlN9nBu6FDlkKyOyuEEsytOyEQ0sliGG3mihw=.c73277da-6006-4271-8660-22ead82a0c41@github.com>
Message-ID: <kmU-2PPtQB5BvlUH7dXEJGKHgqQzNpjjN6z7PGd_0wQ=.614d0f36-cbcd-4ca5-b127-d3ef5de872d0@github.com>

On Fri, 7 Nov 2025 08:50:46 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/mallocHeader.hpp line 155:
>> 
>>> 153: 
>>> 154:   uint8_t* footer_address() const { return ((address)this) + sizeof(MallocHeader) + size(); }
>>> 155: 
>> 
>> Why is this moved to the public interface? If it's for the tests, then use a fixture class and a `friend class` declaration in `MallocHeader`.
>
> No need. Moved to private.

Its still public?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27685#discussion_r2559972870

From coleenp at openjdk.org  Tue Nov 25 21:41:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Nov 2025 21:41:25 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <RNDQHs781HFyKW1yMEG5Lr8xXUviHsgf9oukAqqxSy4=.90abda25-86d0-4ffc-9a80-80bed1479e5b@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <HyEQ8ij1XLyrImL5EOoHePrI3yrfZplRewTApqxVr5g=.d8d55b2d-c058-4d0e-877f-808692b3309a@github.com>
 <GVJWQ8hvpKb24778_jnrldGgpJz8UtcOimIjAgbY1tQ=.ebd4891b-4f8d-4103-9fa1-4cf1dd158ab3@github.com>
 <RNDQHs781HFyKW1yMEG5Lr8xXUviHsgf9oukAqqxSy4=.90abda25-86d0-4ffc-9a80-80bed1479e5b@github.com>
Message-ID: <jJutOh9Je3KBeupEZdOhMNae6t712g61lqsmcnjmFw0=.5f2fae45-cae2-40bf-8a36-0d48ee51a500@github.com>

On Mon, 24 Nov 2025 20:33:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> This was meant to comment your new code, not the old code... Same with the other comment.
>
> My bad, `put_when_absent` asserts that entry is absent.

yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2557661534

From coleenp at openjdk.org  Tue Nov 25 21:41:26 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Nov 2025 21:41:26 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <hvJFdvFA8X97t4m9FEXLzoDeOZK-yPExWn3CWiLm-K4=.90327ad6-2792-4948-859b-325a5f1a1404@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <HyEQ8ij1XLyrImL5EOoHePrI3yrfZplRewTApqxVr5g=.d8d55b2d-c058-4d0e-877f-808692b3309a@github.com>
 <GVJWQ8hvpKb24778_jnrldGgpJz8UtcOimIjAgbY1tQ=.ebd4891b-4f8d-4103-9fa1-4cf1dd158ab3@github.com>
 <RNDQHs781HFyKW1yMEG5Lr8xXUviHsgf9oukAqqxSy4=.90abda25-86d0-4ffc-9a80-80bed1479e5b@github.com>
 <hvJFdvFA8X97t4m9FEXLzoDeOZK-yPExWn3CWiLm-K4=.90327ad6-2792-4948-859b-325a5f1a1404@github.com>
Message-ID: <9YuAlvYqvFlZf_tO4C54VFop99kj9MsfSR-EB5VI46c=.b9735eec-7727-4a5f-82c0-2b2106f3f7cd@github.com>

On Tue, 25 Nov 2025 01:25:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> yes.
>
> That aside we are only calling `add_entry` when we have checked there is no existing entry.

Now also an assert that we really are adding an entry when we've checked that there is no existing entry.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2561526309

From coleenp at openjdk.org  Tue Nov 25 21:41:30 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 25 Nov 2025 21:41:30 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <8fzexwHr8TfZixYCA8ZCbEqnG9vJwqELVGfWiRFYxdU=.0251ecd3-057e-46f2-b545-cdd52dfe2549@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <8fzexwHr8TfZixYCA8ZCbEqnG9vJwqELVGfWiRFYxdU=.0251ecd3-057e-46f2-b545-cdd52dfe2549@github.com>
Message-ID: <IMzSzK3fwApfiEOZU5NNQI8RQI6bzW2Rpqa3lk1ljLI=.0a73feb5-ca13-4705-bc59-dc9e06980b29@github.com>

On Tue, 25 Nov 2025 01:23:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use put_when_absent and add an assert that the message is the same.
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1877:
> 
>> 1875:       // only reach here under the same error condition, so we can ignore the potential race with setting
>> 1876:       // the message, and set it again.
>> 1877:       assert(entry->nest_host_error() == nullptr || strcmp(entry->nest_host_error(), message) == 0, "should be the same message");
> 
> Rather than overwrite the message I would keep the existing null check and maintain three cases:
> 1. No entry so add new one with message
> 2. Existing entry with no-message, so add it
> 3. Existing entry with message - just assert message is the same.

The reason it's like this is that the message will leak if it's not added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2559926663

From vlivanov at openjdk.org  Tue Nov 25 22:40:03 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 25 Nov 2025 22:40:03 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <XTu2dZVoppoRUs-oJ971if55BZ7NONUOKXaum1rAfkw=.9d895fa5-3812-4638-b2f4-68ddcf954978@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

Looks good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27965#pullrequestreview-3507176880

From duke at openjdk.org  Tue Nov 25 23:10:50 2025
From: duke at openjdk.org (duke)
Date: Tue, 25 Nov 2025 23:10:50 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <hOMCRoG0fBNP0LVW9nGwtV13DJskDck_d1pOYeG86cA=.f7332335-e7c6-45f1-8a40-066eafd460be@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

@macarte 
Your change (at version dae852720f1bb1fba43462e1459bada2fd12ef5d) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3577970106

From vlivanov at openjdk.org  Wed Nov 26 02:05:03 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 26 Nov 2025 02:05:03 GMT
Subject: RFR: 8370203 - Add jcmd AOT.end_recording diagnostic command [v7]
In-Reply-To: <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
 <Bae_fRbb3Izdbe9efco9xe9jz7pxYuJ2C6Vv69l94To=.f862e3cc-c934-4a60-8157-badf9af4b828@github.com>
Message-ID: <PVq1YxgqFYXhiQ7oZRGOyC06VNJ5XmcnZiHAM-GwoWk=.f8bf35f2-9b1b-4f98-9006-2d3c8787249c@github.com>

On Tue, 25 Nov 2025 01:01:19 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The command will report back to the user one of the following messages depending on the state of the JVM:
>> 
>> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
>> - Recording has already ended.
>> - Error: Failed to end recording.
>> - Recording ended successfully.
>> 
>> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
>> 
>> - Recording ended successfully.
>> - Recording has already ended.
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check exit value in tests

Test results (hs-tier1 - hs-tier4) are clean.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27965#issuecomment-3578502574

From macarte at openjdk.org  Wed Nov 26 02:05:07 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 26 Nov 2025 02:05:07 GMT
Subject: Integrated: 8370203 - Add jcmd AOT.end_recording diagnostic command
In-Reply-To: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
References: <K6UFvCZlYOytzNuIAFyvCrW0FC2Nrm4o2EXJto1_5Zk=.45a8fdc0-aedc-468f-ae18-cace0140d7b4@github.com>
Message-ID: <4fjwkhgP8pCO4kV1ZVMlwQ5iGkGsuh79xWZG6ltm_wk=.9d410872-f6b7-48d3-8d83-360a61782827@github.com>

On Thu, 23 Oct 2025 23:57:21 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jcmd AOT.end_recording diagnostic command.  When this command is issued, a targeted JVM that is currently recording AOT information will stop recording.  Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode.  Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The command will report back to the user one of the following messages depending on the state of the JVM:
> 
> - AOT.end_recording is unsupported when VM flags -XX:AOTMode=record or -XX:AOTCacheOutput=<file> are missing
> - Recording has already ended.
> - Error: Failed to end recording.
> - Recording ended successfully.
> 
> It follows that issues the command to a JVM that is recording, twice in succession, should (baring internal errors) would produce the following two responses:
> 
> - Recording ended successfully.
> - Recording has already ended.
> 
> Passes tier1 on linux (x64) and windows (x64)

This pull request has now been integrated.

Changeset: 65f1ad61
Author:    Mat Carter <macarte at openjdk.org>
Committer: Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/65f1ad616977428fcb498479132086777dc929cb
Stats:     312 lines in 6 files changed: 312 ins; 0 del; 0 mod

8370203: Add jcmd AOT.end_recording diagnostic command

Reviewed-by: vlivanov, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/27965

From syan at openjdk.org  Wed Nov 26 02:27:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Nov 2025 02:27:48 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails [v6]
In-Reply-To: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
References: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
Message-ID: <txsrYddzglbC5GvP-p0KxB-WSIOcUgMB6Tod-fmIALQ=.b8ce3d3b-98b8-4aa4-ae5e-3a067d5e7b1b@github.com>

> Hi all,
> 
> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis.
> 
> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails.
> 
> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed.
> 
> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java.
> 
> Change has been verified locally, test-fix only, no risk.

SendaoYan 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:

 - Merge branch 'openjdk:master' into jbs8362087
 - Merge branch 'openjdk:master' into jbs8362087
 - Merge branch 'openjdk:master' into jbs8362087
 - Merge branch 'openjdk:master' into jbs8362087
 - Add synchronized lock for addClassOptions
 - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26605/files
  - new: https://git.openjdk.org/jdk/pull/26605/files/997451c5..19095aae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26605&range=04-05

  Stats: 306773 lines in 2659 files changed: 199681 ins; 66049 del; 41043 mod
  Patch: https://git.openjdk.org/jdk/pull/26605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26605/head:pull/26605

PR: https://git.openjdk.org/jdk/pull/26605

From syan at openjdk.org  Wed Nov 26 02:27:53 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 26 Nov 2025 02:27:53 GMT
Subject: RFR: 8362087: Test containers/docker/ShareTmpDir.java intermittent
 fails [v5]
In-Reply-To: <WRO8PbEuo08aZAmlb7T6Ct_JVvWETd0bk5e-OO9XWL4=.1693653d-21cc-4d4e-8c2b-e6f1c90532fb@github.com>
References: <oSRNcbnXITyxH_EsCblndmwkjMgKFN0FOpeJ-HzEd7g=.2288123c-f4e6-42e9-87d9-2b0741f06335@github.com>
 <WRO8PbEuo08aZAmlb7T6Ct_JVvWETd0bk5e-OO9XWL4=.1693653d-21cc-4d4e-8c2b-e6f1c90532fb@github.com>
Message-ID: <Zk9O3hYbCGwYHilfn0JE_eOls1aOjgPfx5dgyKTPox0=.13340aa9-5ce7-456d-8275-509b54bd8b0a@github.com>

On Tue, 28 Oct 2025 04:22:20 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The test containers/docker/ShareTmpDir.java intermittent fails, because before this PR, test assume start two java process in docker container by two threads will make the two java process start simultancely, but in fact, the second java process maybe start slower than the first one, even that the first java process already exit and then the second java process not start yet. If we add `Thread.sleep(2000)` to the second thread at the begin of run() method, will make this intermittent failure to always reproduceable. This prove the anasyis.
>> 
>> If the two java process can not start simultancely, the expected '/tmp/hsperfdata_1 locked' error can not observed. So this test will intermittent fails.
>> 
>> This PR will check all the two java processes started already and runing simultancely before exit, this will make the expected '/tmp/hsperfdata_1 locked' error can be alway observed.
>> 
>> The touch file test/hotspot/jtreg/containers/docker/WaitForFlagFile.java only use for test containers/docker/ShareTmpDir.java.
>> 
>> Change has been verified locally, test-fix only, no risk.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8362087
>  - Merge branch 'openjdk:master' into jbs8362087
>  - Merge branch 'openjdk:master' into jbs8362087
>  - Add synchronized lock for addClassOptions
>  - 8362087: Test containers/docker/ShareTmpDir.java intermittent fails

Looking reviewers for this test bug fix PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26605#issuecomment-3578579229

From stuefe at openjdk.org  Wed Nov 26 05:59:50 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Nov 2025 05:59:50 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v3]
In-Reply-To: <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>
Message-ID: <FP98W0-jEM-QYl75GGUdYBFfEEeiPCAOLBxwzdn540s=.78d96b8c-8c54-4808-80bd-af14f45a480d@github.com>

On Mon, 24 Nov 2025 09:22:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>> 
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.2618391 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be further processed by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> # [...]
>>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> #
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateC...
>
> Paul H?bner 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:
> 
>  - Merge branch 'master' into JDK-8368551
>  - Reviewer suggestions.
>  - Merge branch 'master' into JDK-8368551
>  - Update doc.
>  - Overhaul some core messages again.
>  - Better posix coredump messages.

I am fine with this version, if @dholmes-ora requests are addressed. LGTM.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28174#pullrequestreview-3508978936

From dholmes at openjdk.org  Wed Nov 26 06:31:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 06:31:56 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <IMzSzK3fwApfiEOZU5NNQI8RQI6bzW2Rpqa3lk1ljLI=.0a73feb5-ca13-4705-bc59-dc9e06980b29@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <8fzexwHr8TfZixYCA8ZCbEqnG9vJwqELVGfWiRFYxdU=.0251ecd3-057e-46f2-b545-cdd52dfe2549@github.com>
 <IMzSzK3fwApfiEOZU5NNQI8RQI6bzW2Rpqa3lk1ljLI=.0a73feb5-ca13-4705-bc59-dc9e06980b29@github.com>
Message-ID: <xx3AqZD7aPAQT_AU6tnS-L_UsNaojm--mPH_N5e5OkY=.50871997-3d84-434d-975d-1739ccb156f4@github.com>

On Tue, 25 Nov 2025 13:06:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.cpp line 1877:
>> 
>>> 1875:       // only reach here under the same error condition, so we can ignore the potential race with setting
>>> 1876:       // the message, and set it again.
>>> 1877:       assert(entry->nest_host_error() == nullptr || strcmp(entry->nest_host_error(), message) == 0, "should be the same message");
>> 
>> Rather than overwrite the message I would keep the existing null check and maintain three cases:
>> 1. No entry so add new one with message
>> 2. Existing entry with no-message, so add it
>> 3. Existing entry with message - just assert message is the same.
>
> The reason it's like this is that the message will leak if it's not added.

How does it leak - it originates from a stringStream that will go out of scope???

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2563474380

From dholmes at openjdk.org  Wed Nov 26 06:39:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 06:39:57 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
Message-ID: <34roqOGICaX1kMEwZ4EZGUGILqRAsaz9aUUoFTpjKsc=.da12f546-9f60-4ba2-9b23-3f4c59b0a832@github.com>

On Mon, 24 Nov 2025 18:40:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use put_when_absent and add an assert that the message is the same.

src/hotspot/share/classfile/resolutionErrors.cpp line 135:

> 133:   }
> 134:   _nest_host_error = message;
> 135: }

I don't see the need for this - just don't overwrite the message.

src/hotspot/share/classfile/systemDictionary.cpp line 1869:

> 1867:     if (entry == nullptr) {
> 1868:       // Only add a new resolution error if one hasn't been found for this constant pool index. In this case,
> 1869:       // resolution succeeded but there's an error in this nest host.

Suggestion:

      // Only add a new entry to the resolution error table if one hasn't been found for this 
      // constant pool index. In this case resolution succeeded but there's an error in this nest host
      // that we use the table to record.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2563481656
PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2563487454

From duke at openjdk.org  Wed Nov 26 06:42:56 2025
From: duke at openjdk.org (=?UTF-8?B?TWFyw61h?= Arias de Reyna =?UTF-8?B?RG9tw61uZ3Vleg==?=)
Date: Wed, 26 Nov 2025 06:42:56 GMT
Subject: Integrated: 8372253: Improve logging to show why a class was excluded
 from AOT Cache
In-Reply-To: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
References: <zIonqRxYhYMnp6px4NAASD9HM3LJxUFptbKxfpHoYnQ=.e189769e-7e1c-4b58-8011-4f1e836a628a@github.com>
Message-ID: <gWqyRJ9plWd9iX98sVA81A3JFJWwvhW0obog-hY-E7s=.a2f8c342-49c9-4345-a92a-5621575b0c68@github.com>

On Thu, 20 Nov 2025 09:20:11 GMT, Mar?a Arias de Reyna Dom?nguez <duke at openjdk.org> wrote:

> Fixes: https://bugs.openjdk.org/browse/JDK-8372253
> 
> When dumping the AOT Cache file, some classes throw a verification error and are excluded from the cache:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext 
> [warning][aot] Skipping io/netty/handler/ssl/OpenSslClientContext: Failed verification
> 
> 
> This PR improves the log message by adding the cause of this failure:
> 
> 
> [warning][aot] Preload Warning: Verification failed for io.netty.handler.ssl.OpenSslClientContext because a java.lang.NoClassDefFoundError was thrown: io/netty/internal/tcnative/SSLPrivateKeyMethod

This pull request has now been integrated.

Changeset: 3ef3f259
Author:    Mar?a Arias de Reyna Dom?nguez <mariasde at ibm.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ef3f259bbf4bf40638f53319ec4eea7fdd147e1
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8372253: Improve logging to show why a class was excluded from AOT Cache

Reviewed-by: asmehra, iklam

-------------

PR: https://git.openjdk.org/jdk/pull/28413

From phubner at openjdk.org  Wed Nov 26 08:35:58 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 26 Nov 2025 08:35:58 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v3]
In-Reply-To: <FP98W0-jEM-QYl75GGUdYBFfEEeiPCAOLBxwzdn540s=.78d96b8c-8c54-4808-80bd-af14f45a480d@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>
 <FP98W0-jEM-QYl75GGUdYBFfEEeiPCAOLBxwzdn540s=.78d96b8c-8c54-4808-80bd-af14f45a480d@github.com>
Message-ID: <CyrPVaKzBsCNlRlXNIfQZbQwLMNNv1Awg0yOmijF46o=.1a022960-68c1-4c5d-a50f-b1db1787f868@github.com>

On Wed, 26 Nov 2025 05:57:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Paul H?bner 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:
>> 
>>  - Merge branch 'master' into JDK-8368551
>>  - Reviewer suggestions.
>>  - Merge branch 'master' into JDK-8368551
>>  - Update doc.
>>  - Overhaul some core messages again.
>>  - Better posix coredump messages.
>
> I am fine with this version, if @dholmes-ora requests are addressed. LGTM.

Thanks so much for the feedback @tstuefe @dholmes-ora.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28174#issuecomment-3580117297

From duke at openjdk.org  Wed Nov 26 08:38:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 26 Nov 2025 08:38:59 GMT
Subject: RFR: 8368551: Core dump warning may be confusing [v3]
In-Reply-To: <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
 <62qrV32D9LdwzUk9n9m_-M6NbaSrcivVAuym3Q99AI8=.493664b0-6f54-4773-8f9f-0ed538c294fa@github.com>
Message-ID: <7StxqocP1uJISgLnZuND-r_SlhfBxiqXEh7b9YrLpe0=.d4bc48c4-0f1b-47ef-a479-45fb8359b6ca@github.com>

On Mon, 24 Nov 2025 09:22:46 GMT, Paul H?bner <phubner at openjdk.org> wrote:

>> Hi all,
>> 
>> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
>> 
>> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
>> 
>> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
>> 
>> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # CreateCoredumpOnCrash turned off, no core file dumped
>> 
>> **Scenario 2: `get_core_path` errors**
>> 
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: core.2618391 (may not exist)
>> 
>> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be further processed by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> # [...]
>>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>>> #
>> 
>> **Scenario 4: the resource limit for core dumps could not be determined**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> # [...]
>>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
>> 
>> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>>> Java HotSpot(TM) 64-Bit Server VM warning: CreateC...
>
> Paul H?bner 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:
> 
>  - Merge branch 'master' into JDK-8368551
>  - Reviewer suggestions.
>  - Merge branch 'master' into JDK-8368551
>  - Update doc.
>  - Overhaul some core messages again.
>  - Better posix coredump messages.

@Arraying 
Your change (at version 3306d0defa1c48608db0b835714d5d44ef8f24ec) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28174#issuecomment-3580128270

From azafari at openjdk.org  Wed Nov 26 11:13:21 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 26 Nov 2025 11:13:21 GMT
Subject: RFR: 8369393: NMT: poison the malloc header and footer under ASAN
 build
Message-ID: <B4rNtXVtYBI3tlTO_bBdxJkB05iXbJQWAmDchEv_jyk=.c04a41a5-753f-4b08-bfaa-54e04e084fd3@github.com>

Under ASAN builds and when NMT is enabled, the header and footer of MallocHeader are poisoned/unpoisoned at malloc/realloc/free times.
Checking the integrity of memory blocks is off under ASAN builds.

-------------

Commit messages:
 - 8369393: NMT: poison the malloc header and footer under ASAN build

Changes: https://git.openjdk.org/jdk/pull/28503/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28503&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369393
  Stats: 122 lines in 5 files changed: 108 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28503.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28503/head:pull/28503

PR: https://git.openjdk.org/jdk/pull/28503

From coleenp at openjdk.org  Wed Nov 26 13:04:51 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 13:04:51 GMT
Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
References: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
Message-ID: <cRy9DU3gNU5iSDny-DXiIkvT2Bd5nBw0Pbsk1eo5GTU=.77cb9c7a-5050-4696-996a-703b38576b9a@github.com>

On Wed, 26 Nov 2025 12:10:55 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
> 
> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
> 
> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
> 
> Testing: jdk_jfr, manual AOT verification, stress testing
> 
> Thanks
> Markus

Why did you write a different concurrent hash table?  Why wasn't the existing one good enough?  You say it's simpler but this adds many lines of code that someone has to read.

src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68:

> 66: 
> 67:   void on_link(const Symbols::Entry* entry);
> 68:   void on_unlink(const Symbols::Entry* entry);

What is Symbols ? Is it a JFR thing, so should it be JfrSymbols ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/28505#pullrequestreview-3510858860
PR Review Comment: https://git.openjdk.org/jdk/pull/28505#discussion_r2564923817

From phubner at openjdk.org  Wed Nov 26 13:08:29 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Wed, 26 Nov 2025 13:08:29 GMT
Subject: Integrated: 8368551: Core dump warning may be confusing
In-Reply-To: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
References: <UOprvi_JWPwwgYI5Bvelr1JD7DjcQySq57c8AGK8fnM=.8008e7f4-30c2-4d99-afe2-6d32f829e891@github.com>
Message-ID: <6m41zI3wLTm0A5r1wozVVol0ubqPBJodPSaZIaJnZtA=.85865e3b-b626-4dfa-8a2c-d76248257067@github.com>

On Thu, 6 Nov 2025 08:51:38 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> The `os::check_core_dump_prerequisites` function is used to build the strings of 1) warnings if `CreateCoredumpOnCrash` is specified explicitly and some prerequisite is not fulfilled (fully), and 2) the location of the dump when the VM aborts on error.
> 
> This is fine for many cases, but there are some edgecases on POSIX systems where the warning makes little sense. For example, as reported in the issue:
>> OpenJDK 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but /shared/cores/core-%e-585191 (max size 0 k). To ensure a full core dump, try "ulimit -c unlimited" before starting Java again
> 
> This PR refactors overhauls some of these edge cases to ensure that the warning messages and core locations are more clear and user-friendly.
> 
> **Scenario 1: `CreateCoredumpOnCrash` is disabled**
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # CreateCoredumpOnCrash turned off, no core file dumped
> 
> **Scenario 2: `get_core_path` errors**
> 
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the core path couldn't be determined. It commonly defaults to core.2618391
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: core.2618391 (may not exist)
> 
> **Scenario 3: the user processes core dump with e.g. `systemd-coredump`**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps may be further processed by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>> # [...]
>> # Core dump will be written. Default location: Determined by the following: "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" (alternatively, falling back to /home/foo/bar/betterCoreMsg/core.3005883)
>> #
> 
> **Scenario 4: the resource limit for core dumps could not be determined**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but the rlimit couldn't be determined. If resource limits permit, the core dump will be located at /tmp/cores/core.%e.2623318.%h.%t
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> # [...]
>> # Core dump will be written. Default location: /tmp/cores/core.%e.2623318.%h.%t (may not exist)
> 
> **Scenarios 5, 6, 7: ulimit of 0, 1024, and unlimited**
>> Java HotSpot(TM) 64-Bit Server VM warning: CreateCoredumpOnCrash specified, but core dumps have been disab...

This pull request has now been integrated.

Changeset: c146805d
Author:    Paul H?bner <phubner at openjdk.org>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c146805da5708b479bf8dd0180acd06657b72788
Stats:     33 lines in 3 files changed: 19 ins; 0 del; 14 mod

8368551: Core dump warning may be confusing

Reviewed-by: stuefe, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/28174

From coleenp at openjdk.org  Wed Nov 26 13:23:56 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 13:23:56 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <34roqOGICaX1kMEwZ4EZGUGILqRAsaz9aUUoFTpjKsc=.da12f546-9f60-4ba2-9b23-3f4c59b0a832@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <34roqOGICaX1kMEwZ4EZGUGILqRAsaz9aUUoFTpjKsc=.da12f546-9f60-4ba2-9b23-3f4c59b0a832@github.com>
Message-ID: <T1GYITmRvbWTW6J9_3VxswfgfKTmdqD1G1FfXznlcbg=.63e9601c-a3db-47d7-b6fc-47e5f3867ac4@github.com>

On Wed, 26 Nov 2025 06:32:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use put_when_absent and add an assert that the message is the same.
>
> src/hotspot/share/classfile/systemDictionary.cpp line 1869:
> 
>> 1867:     if (entry == nullptr) {
>> 1868:       // Only add a new resolution error if one hasn't been found for this constant pool index. In this case,
>> 1869:       // resolution succeeded but there's an error in this nest host.
> 
> Suggestion:
> 
>       // Only add a new entry to the resolution error table if one hasn't been found for this 
>       // constant pool index. In this case resolution succeeded but there's an error in this nest host
>       // that we use the table to record.

I do not believe this is true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2564979562

From coleenp at openjdk.org  Wed Nov 26 13:23:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 13:23:57 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <xx3AqZD7aPAQT_AU6tnS-L_UsNaojm--mPH_N5e5OkY=.50871997-3d84-434d-975d-1739ccb156f4@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <8fzexwHr8TfZixYCA8ZCbEqnG9vJwqELVGfWiRFYxdU=.0251ecd3-057e-46f2-b545-cdd52dfe2549@github.com>
 <IMzSzK3fwApfiEOZU5NNQI8RQI6bzW2Rpqa3lk1ljLI=.0a73feb5-ca13-4705-bc59-dc9e06980b29@github.com>
 <xx3AqZD7aPAQT_AU6tnS-L_UsNaojm--mPH_N5e5OkY=.50871997-3d84-434d-975d-1739ccb156f4@github.com>
Message-ID: <jYo2TV0T6xCDJ26YlUz3A-DyM0caupTMEI7p1u3yAaM=.524c19ea-99d9-4eeb-82de-ba4f9a6cc696@github.com>

On Wed, 26 Nov 2025 06:28:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The reason it's like this is that the message will leak if it's not added.
>
> How does it leak - it originates from a stringStream that will go out of scope???

Both of the callers in InstanceKlass::nest_host() add the error from a C heap allocated string:


        const char* msg = ss.as_string(true /* on C-heap */);
        constantPoolHandle cph(THREAD, constants());
        SystemDictionary::add_nest_host_error(cph, _nest_host_index, msg);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2564983902

From coleenp at openjdk.org  Wed Nov 26 13:23:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 13:23:58 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <jYo2TV0T6xCDJ26YlUz3A-DyM0caupTMEI7p1u3yAaM=.524c19ea-99d9-4eeb-82de-ba4f9a6cc696@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <8fzexwHr8TfZixYCA8ZCbEqnG9vJwqELVGfWiRFYxdU=.0251ecd3-057e-46f2-b545-cdd52dfe2549@github.com>
 <IMzSzK3fwApfiEOZU5NNQI8RQI6bzW2Rpqa3lk1ljLI=.0a73feb5-ca13-4705-bc59-dc9e06980b29@github.com>
 <xx3AqZD7aPAQT_AU6tnS-L_UsNaojm--mPH_N5e5OkY=.50871997-3d84-434d-975d-1739ccb156f4@github.com>
 <jYo2TV0T6xCDJ26YlUz3A-DyM0caupTMEI7p1u3yAaM=.524c19ea-99d9-4eeb-82de-ba4f9a6cc696@github.com>
Message-ID: <7W2S6v1P20QKmd0bupIbsUYXurDo7LUvMSQzRyMnePE=.2b98ac72-2242-40ea-b962-b772c3c2b595@github.com>

On Wed, 26 Nov 2025 13:19:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> How does it leak - it originates from a stringStream that will go out of scope???
>
> Both of the callers in InstanceKlass::nest_host() add the error from a C heap allocated string:
> 
> 
>         const char* msg = ss.as_string(true /* on C-heap */);
>         constantPoolHandle cph(THREAD, constants());
>         SystemDictionary::add_nest_host_error(cph, _nest_host_index, msg);

Ioi and Johan noticed this and Johan has a further improvement to ResourceAllocate the string so that if we don't add it, it will get freed, but that's not the case with the caller today.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2564989567

From mgronlun at openjdk.org  Wed Nov 26 13:49:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 26 Nov 2025 13:49:50 GMT
Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for
 class loading
In-Reply-To: <cRy9DU3gNU5iSDny-DXiIkvT2Bd5nBw0Pbsk1eo5GTU=.77cb9c7a-5050-4696-996a-703b38576b9a@github.com>
References: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
 <cRy9DU3gNU5iSDny-DXiIkvT2Bd5nBw0Pbsk1eo5GTU=.77cb9c7a-5050-4696-996a-703b38576b9a@github.com>
Message-ID: <Uk00VZXmC8Jlk7LhndhvhDLPeEikFqzdzeSfbxzgviY=.7984fe10-e731-42b0-a7a6-1e3dc02ee254@github.com>

On Wed, 26 Nov 2025 13:01:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Greetings,
>> 
>> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
>> 
>> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
>> 
>> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
>> 
>> Testing: jdk_jfr, manual AOT verification, stress testing
>> 
>> Thanks
>> Markus
>
> src/hotspot/share/jfr/support/jfrSymbolTable.hpp line 68:
> 
>> 66: 
>> 67:   void on_link(const Symbols::Entry* entry);
>> 68:   void on_unlink(const Symbols::Entry* entry);
> 
> What is Symbols ? Is it a JFR thing, so should it be JfrSymbols ?

It's a more effective version of a concurrent hash table because we employ invariants that apply only to JFR (no concurrency state (hazard ptrs, global counters etc) is needed to track concurrency; only CAS insertions are made into the mapped primary bucket, searches are stable searches in the epoch-current list).

Symbols are mainly the regular runtime Symbols, but we also have an extension for tracking const char*s c-strings.

A JFR symbol is a constant pool construct, mapped onto an epoch-relative id.

Since the Symbols here are typedeffed inside a JFR class, its scope is already a JFR specific construct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28505#discussion_r2565077778

From mgronlun at openjdk.org  Wed Nov 26 14:27:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 26 Nov 2025 14:27:38 GMT
Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for
 class loading [v2]
In-Reply-To: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
References: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
Message-ID: <OyQofoNin0y1Ao6OwLVkStDHh6_w29O9GqmEswJWFP8=.7741bda0-15ce-4864-a90a-76b4084b2347@github.com>

> Greetings,
> 
> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
> 
> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
> 
> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
> 
> Testing: jdk_jfr, manual AOT verification, stress testing
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  JFR_ONLY

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28505/files
  - new: https://git.openjdk.org/jdk/pull/28505/files/2c6e4fb6..350203ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505

PR: https://git.openjdk.org/jdk/pull/28505

From mgronlun at openjdk.org  Wed Nov 26 15:23:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 26 Nov 2025 15:23:11 GMT
Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for
 class loading [v3]
In-Reply-To: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
References: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
Message-ID: <YttMGOlzIfuInzv25iDLQMHjjiMNw0HPLZCEAhcnaMo=.f6f88b31-763b-4424-ae20-d55d2bbdd086@github.com>

> Greetings,
> 
> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
> 
> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
> 
> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
> 
> Testing: jdk_jfr, manual AOT verification, stress testing
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  include apa

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28505/files
  - new: https://git.openjdk.org/jdk/pull/28505/files/350203ca..af55c2a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=01-02

  Stats: 4 lines in 2 files changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505

PR: https://git.openjdk.org/jdk/pull/28505

From tschatzl at openjdk.org  Wed Nov 26 15:52:48 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Nov 2025 15:52:48 GMT
Subject: RFR: 8372571: ResourceHashTable for some AOT data structures miss
 placement operator when allocating
In-Reply-To: <mOp0BjsFvsVhaPsKxWpVeAo_TIphvPvflTin211aqLY=.8ad46172-71a2-4903-84cd-91d71c666a28@github.com>
References: <mOp0BjsFvsVhaPsKxWpVeAo_TIphvPvflTin211aqLY=.8ad46172-71a2-4903-84cd-91d71c666a28@github.com>
Message-ID: <KtDqNKwWsXj7GX1oW_Tw7G_uAy3c-U8YDHYSqef3YWg=.b9b22b8c-35f6-411c-898a-df6682d17192@github.com>

On Wed, 26 Nov 2025 15:41:25 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup adding two missing placement operators when allocating `ResizeableHashTable`s during AOT dumping. Both table instances are clearly meant to be accessible as they are assigned to static members and accessed outside of the method creating them.
> 
> There is no problematic `ResourceMark` though, so there should be no current impact.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

That failing test looks like a compiler issue, not related.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28510#issuecomment-3581975822

From tschatzl at openjdk.org  Wed Nov 26 15:52:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Nov 2025 15:52:47 GMT
Subject: RFR: 8372571: ResourceHashTable for some AOT data structures miss
 placement operator when allocating
Message-ID: <mOp0BjsFvsVhaPsKxWpVeAo_TIphvPvflTin211aqLY=.8ad46172-71a2-4903-84cd-91d71c666a28@github.com>

Hi all,

  please review this cleanup adding two missing placement operators when allocating `ResizeableHashTable`s during AOT dumping. Both table instances are clearly meant to be accessible as they are assigned to static members and accessed outside of the method creating them.

There is no problematic `ResourceMark` though, so there should be no current impact.

Testing: gha

Thanks,
  Thomas

-------------

Commit messages:
 - 8372571

Changes: https://git.openjdk.org/jdk/pull/28510/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28510&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372571
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28510/head:pull/28510

PR: https://git.openjdk.org/jdk/pull/28510

From mgronlun at openjdk.org  Wed Nov 26 19:25:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 26 Nov 2025 19:25:34 GMT
Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for
 class loading [v4]
In-Reply-To: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
References: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
Message-ID: <TmcpyroNAqcLoytYS-iUH9ePlbLdbBm5dOqBoc3qexg=.e5287b22-51b5-4dfc-aca8-9d333adee654@github.com>

> Greetings,
> 
> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
> 
> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
> 
> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
> 
> Testing: jdk_jfr, manual AOT verification, stress testing
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  adjustments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28505/files
  - new: https://git.openjdk.org/jdk/pull/28505/files/af55c2a7..d312adba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=02-03

  Stats: 50 lines in 4 files changed: 22 ins; 3 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/28505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505

PR: https://git.openjdk.org/jdk/pull/28505

From dholmes at openjdk.org  Wed Nov 26 20:13:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 20:13:54 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <T1GYITmRvbWTW6J9_3VxswfgfKTmdqD1G1FfXznlcbg=.63e9601c-a3db-47d7-b6fc-47e5f3867ac4@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <34roqOGICaX1kMEwZ4EZGUGILqRAsaz9aUUoFTpjKsc=.da12f546-9f60-4ba2-9b23-3f4c59b0a832@github.com>
 <T1GYITmRvbWTW6J9_3VxswfgfKTmdqD1G1FfXznlcbg=.63e9601c-a3db-47d7-b6fc-47e5f3867ac4@github.com>
Message-ID: <EIaKIkygTMyrTAHIYfQOpBgE5ZUtbuhmo4ibSbwNLx0=.4b205847-38bf-49fc-90ff-798c1ab70ff4@github.com>

On Wed, 26 Nov 2025 13:18:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/systemDictionary.cpp line 1869:
>> 
>>> 1867:     if (entry == nullptr) {
>>> 1868:       // Only add a new resolution error if one hasn't been found for this constant pool index. In this case,
>>> 1869:       // resolution succeeded but there's an error in this nest host.
>> 
>> Suggestion:
>> 
>>       // Only add a new entry to the resolution error table if one hasn't been found for this 
>>       // constant pool index. In this case resolution succeeded but there's an error in this nest host
>>       // that we use the table to record.
>
> I do not believe this is true.

I'm only re-stating, in a clearer way, what was previously there. I believe it is true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2566369887

From dholmes at openjdk.org  Wed Nov 26 21:15:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 21:15:53 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
Message-ID: <9lKNBueOAUP-4F8l_lYBPnL4aWonqjixEByExQLTVCA=.c7b62aa1-86b2-44d1-a8a4-080cc6bb71cf@github.com>

On Mon, 24 Nov 2025 18:40:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use put_when_absent and add an assert that the message is the same.

After a long discussion with Coleen we are on the same page with this.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28438#pullrequestreview-3512767774

From dholmes at openjdk.org  Wed Nov 26 21:15:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 21:15:55 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <34roqOGICaX1kMEwZ4EZGUGILqRAsaz9aUUoFTpjKsc=.da12f546-9f60-4ba2-9b23-3f4c59b0a832@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <34roqOGICaX1kMEwZ4EZGUGILqRAsaz9aUUoFTpjKsc=.da12f546-9f60-4ba2-9b23-3f4c59b0a832@github.com>
Message-ID: <ExVahJT9WMpOaB7EzzaX4VmBrkPjrAMhx0InwxCJXTw=.6d7ad081-3fd6-43ba-bac4-691bf066190c@github.com>

On Wed, 26 Nov 2025 06:30:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use put_when_absent and add an assert that the message is the same.
>
> src/hotspot/share/classfile/resolutionErrors.cpp line 135:
> 
>> 133:   }
>> 134:   _nest_host_error = message;
>> 135: }
> 
> I don't see the need for this - just don't overwrite the message.

Okay I now see the need for this - had a long chat with Coleen.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2566499898

From dholmes at openjdk.org  Wed Nov 26 21:15:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Nov 2025 21:15:56 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <7W2S6v1P20QKmd0bupIbsUYXurDo7LUvMSQzRyMnePE=.2b98ac72-2242-40ea-b962-b772c3c2b595@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <8fzexwHr8TfZixYCA8ZCbEqnG9vJwqELVGfWiRFYxdU=.0251ecd3-057e-46f2-b545-cdd52dfe2549@github.com>
 <IMzSzK3fwApfiEOZU5NNQI8RQI6bzW2Rpqa3lk1ljLI=.0a73feb5-ca13-4705-bc59-dc9e06980b29@github.com>
 <xx3AqZD7aPAQT_AU6tnS-L_UsNaojm--mPH_N5e5OkY=.50871997-3d84-434d-975d-1739ccb156f4@github.com>
 <jYo2TV0T6xCDJ26YlUz3A-DyM0caupTMEI7p1u3yAaM=.524c19ea-99d9-4eeb-82de-ba4f9a6cc696@github.com>
 <7W2S6v1P20QKmd0bupIbsUYXurDo7LUvMSQzRyMnePE=.2b98ac72-2242-40ea-b962-b772c3c2b595@github.com>
Message-ID: <uzirGpwzCxuUhe4MY5U6V9kF__RITjCAeRmxruoxuqo=.dbed0597-1d8b-4eea-8fc6-4742fbf8d1a9@github.com>

On Wed, 26 Nov 2025 13:21:06 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Both of the callers in InstanceKlass::nest_host() add the error from a C heap allocated string:
>> 
>> 
>>         const char* msg = ss.as_string(true /* on C-heap */);
>>         constantPoolHandle cph(THREAD, constants());
>>         SystemDictionary::add_nest_host_error(cph, _nest_host_index, msg);
>
> Ioi and Johan noticed this and Johan has a further improvement to ResourceAllocate the string so that if we don't add it, it will get freed, but that's not the case with the caller today.

Yep I missed that sorry - and of course stringStream no longer behaves the way it used to. We need a follow up to properly deal with the message "ownership" issue in the ResolutionErrorEntry constructors so that they get freed appropriately when needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2566503333

From jnorlinder at openjdk.org  Wed Nov 26 23:18:57 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Wed, 26 Nov 2025 23:18:57 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time
Message-ID: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>

For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.

The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):


// Switch to using fast clocks for thread cpu time if
// the sys_clock_getres() returns 0 error code.
// Note, that some kernels may support the current thread
// clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
// returned by the pthread_getcpuclockid().
// If the fast Posix clocks are supported then the sys_clock_getres()
// must return at least tp.tv_sec == 0 which means a resolution
// better than 1 sec. This is extra check for reliability.


There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 

During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.

-------------

Commit messages:
 - Remove _supports_fast_thread_cpu_time

Changes: https://git.openjdk.org/jdk/pull/28516/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28516&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372625
  Stats: 65 lines in 2 files changed: 0 ins; 49 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/28516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28516/head:pull/28516

PR: https://git.openjdk.org/jdk/pull/28516

From coleenp at openjdk.org  Wed Nov 26 23:28:11 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 23:28:11 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v5]
In-Reply-To: <EIaKIkygTMyrTAHIYfQOpBgE5ZUtbuhmo4ibSbwNLx0=.4b205847-38bf-49fc-90ff-798c1ab70ff4@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <uSV25dQbifbvoQpABKdfuHO5ymkxVO1B9COoQJJRHi0=.e1f1bba0-46c4-4d94-a689-1662ebf57d3c@github.com>
 <34roqOGICaX1kMEwZ4EZGUGILqRAsaz9aUUoFTpjKsc=.da12f546-9f60-4ba2-9b23-3f4c59b0a832@github.com>
 <T1GYITmRvbWTW6J9_3VxswfgfKTmdqD1G1FfXznlcbg=.63e9601c-a3db-47d7-b6fc-47e5f3867ac4@github.com>
 <EIaKIkygTMyrTAHIYfQOpBgE5ZUtbuhmo4ibSbwNLx0=.4b205847-38bf-49fc-90ff-798c1ab70ff4@github.com>
Message-ID: <_6s_JKLzbSeoQOEkLS8gerWPUWFKe743NTlxdNzfr1A=.58a6dba6-286e-46cf-b70f-a446cea5a287@github.com>

On Wed, 26 Nov 2025 20:10:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I do not believe this is true.
>
> I'm only re-stating, in a clearer way, what was previously there. I believe it is true.

Yes, it is true, I didn't read your suggestion correctly.  It does clarify things and I shouldn't have called it a "resolution error" since that's not true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2566709872

From coleenp at openjdk.org  Wed Nov 26 23:28:10 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 26 Nov 2025 23:28:10 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v6]
In-Reply-To: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
Message-ID: <R2jugSN2iPPOseR_z1XdPvCk3wiXHMy90mWl2VK_uzY=.85d46ab8-8fd5-4ca7-ad84-6dfe1b74fec6@github.com>

> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
> 
> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
> 
> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
> 
> Tested with submitted reproducer and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/classfile/systemDictionary.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28438/files
  - new: https://git.openjdk.org/jdk/pull/28438/files/a0c53929..a9f4e7f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=04-05

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28438/head:pull/28438

PR: https://git.openjdk.org/jdk/pull/28438

From nbenalla at openjdk.org  Thu Nov 27 00:08:17 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 00:08:17 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
Message-ID: <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>

> Get JDK 27 underway.

Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Update --release 26 symbol information for JDK 26 build 25
   The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
 - revert MAX_COLUMNS to 80
 - Update LATEST_MAJOR_VERSION in Versions.java
 - Merge branch 'master' into start-of-release-27
 - Merge branch 'master' into start-of-release-27
 - Merge branch 'master' into start-of-release-27
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Updates due to the generate-symbol-data.sh location changing in 8367259
 - Merge branch 'master' into start-of-release-27
 - update links to JVMS 26 and 27
 - ... and 2 more: https://git.openjdk.org/jdk/compare/53a97205...78895b2b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28130/files
  - new: https://git.openjdk.org/jdk/pull/28130/files/3d9eb308..78895b2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=04-05

  Stats: 69573 lines in 1019 files changed: 46890 ins; 15885 del; 6798 mod
  Patch: https://git.openjdk.org/jdk/pull/28130.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130

PR: https://git.openjdk.org/jdk/pull/28130

From dholmes at openjdk.org  Thu Nov 27 00:13:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Nov 2025 00:13:54 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v2]
In-Reply-To: <NxsfsUR-de39aCb9hWqhnJrvc8zZYnsK9YICN6388ag=.b5069d4f-5b1e-4d1d-8e00-b746e6fbe4c6@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <mGPsqTRYX8Un8WOybW1-ma8Q34BI52g_uBz8pP70UKo=.674a3884-17ab-4bd7-b13f-a3379daf8a64@github.com>
 <99vzqFt9enSh6Q9JOVCTaxBpsI_hipkG43MqMvP7W_I=.83d91ede-d0f9-42dc-9692-8d4e138db240@github.com>
 <xkSuBAfZV3EGECFif03Jsg-IpnBo9cY00e3n96AemiA=.3ed6473a-b0ea-49a9-b1cb-62d0ce6507d3@github.com>
 <NxsfsUR-de39aCb9hWqhnJrvc8zZYnsK9YICN6388ag=.b5069d4f-5b1e-4d1d-8e00-b746e6fbe4c6@github.com>
Message-ID: <i7JLZj4T7LXffsAHqcLqQ3RxHmjvY30Tuay3j-W25zc=.89cb15fd-ad4d-4763-bffb-8db76da01b21@github.com>

On Sat, 22 Nov 2025 11:58:49 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> In the `SystemDictionary` case, we're fine. You wouldn't think so, but we are. That's because message and cause_msg are resource allocated, and those strings are strdup:ed in the constructor of the table entry. `InstanceKlass::next_host` has a memory leak though, because `ResolutionErrorEntry` *does* take ownership of the underlying string pointer, so we have this:
>> 
>> ```c++
>>       const char* msg = ss.as_string(true /* on C-heap */);
>>       constantPoolHandle cph(THREAD, constants());
>>       SystemDictionary::add_nest_host_error(cph, _nest_host_index, msg);
>>       // ... down the callstack we go, reaching the constructor call:
>>        ResolutionErrorEntry *entry = new ResolutionErrorEntry(message);
>>        ResolutionErrorEntry(const char* message):
>>         _error(nullptr),
>>         _message(nullptr),
>>         _cause(nullptr),
>>         _cause_msg(nullptr),
>> 
>>         _nest_host_error(message) {} // <-- Noooo
>> 
>> 
>> As opposed to the other constructor, which looks like this:
>> 
>> ```c++
>> // This is the call to the constructor this time:
>>   ResolutionErrorEntry *entry = new ResolutionErrorEntry(error, message, cause, cause_msg);
>> ResolutionErrorEntry::ResolutionErrorEntry(Symbol* error, const char* message,
>>                                            Symbol* cause, const char* cause_msg):
>>         _error(error),
>>         _message(message != nullptr ? os::strdup(message) : nullptr),
>>         _cause(cause),
>>         _cause_msg(cause_msg != nullptr ? os::strdup(cause_msg) : nullptr),
>>         _nest_host_error(nullptr) {
>> 
>>   Symbol::maybe_increment_refcount(_error);
>>   Symbol::maybe_increment_refcount(_cause);
>> }
>> 
>> 
>> This is actually pretty bad :-/, I'd really appreciate it if we could make these types of bugs a bit more shallow at the time of writing them.
>> 
>> Maybe it'd be nice to have a type that tells the reader that an object doesn't intend to free a received pointer on its destruction? This is a very small sketch of something illustrating kind of what I mean:
>> 
>> ```c++
>> template<typename T>
>> using Borrow = T*;
>> template<typename T>
>> using Own = T*;
>> 
>> // "I'll take a string, but I don't intend to be responsible for freeing it"
>> const char* os::strdup(Borrow<const char>, MemTag) { /* ... */}
>> 
>> class SystemDictionary {
>>   Own<const char> _message; // I own this, and so I intend to free it when I'm destroyed
>>   Own<const char> _cause_msg; // Same here
>> 
>>   // "I'll take a message and a cause_msg, and I won'...
>
> I made a ticket for this: [8372373](https://bugs.openjdk.org/browse/JDK-8372373)

@jdksjolen just to clarify one thing. There is a reason we defined the second constructor to not have to strdup. Given we start with a `stringStream` we have to first convert that to a `char*` representation, which is done via a C-heap array allocation. If the constructor then `strdup`'d that then we'd be copying the string twice. So instead we expect to get the C-heap version (which should also get freed when needed, but I think we missed that part).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2566763539

From nbenalla at openjdk.org  Thu Nov 27 00:27:50 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 00:27:50 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
Message-ID: <tA5MCownWk5rOgrTIV535ZBZOsTHJU5YeZN6CR41FT4=.332bc50e-a918-4e64-95be-88a141c9593a@github.com>

On Thu, 27 Nov 2025 00:08:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/4bfba094...78895b2b

I had to make some changes to respect the 80 character limit we used to have.
Instead of showing a long list for the --release values in the javac help output we show the following:

  --target <release>, -target <release>
        Generate class files suitable for the specified Java SE release.
        Supported releases: 
            8, 9, 10, ..., 25, 26, 27

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28130#issuecomment-3583630744

From iris at openjdk.org  Thu Nov 27 00:37:53 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Nov 2025 00:37:53 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
Message-ID: <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>

On Thu, 27 Nov 2025 00:08:17 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Get JDK 27 underway.
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Update --release 26 symbol information for JDK 26 build 25
>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>  - revert MAX_COLUMNS to 80
>  - Update LATEST_MAJOR_VERSION in Versions.java
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Merge branch 'master' into start-of-release-27
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>  - Merge branch 'master' into start-of-release-27
>  - update links to JVMS 26 and 27
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a52f9076...78895b2b

The changes in com.sun.tools.javac.main.Option don't appear strictly necessary for the start of release updates...

test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:

> 48: public class HelpOutputColumnWidthTest extends TestRunner {
> 49: 
> 50:     public static final int MAX_COLUMNS = 80;

I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3513096801
PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566785560

From iris at openjdk.org  Thu Nov 27 00:37:54 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Nov 2025 00:37:54 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
 <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
Message-ID: <EZ6E_tH3VAGcKj7bcwIV08SJFx82vCibl-HDKki_sRY=.1ee06657-2d3e-441e-b991-96e5ce3b1b3b@github.com>

On Thu, 27 Nov 2025 00:31:23 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Update --release 26 symbol information for JDK 26 build 25
>>    The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/
>>  - revert MAX_COLUMNS to 80
>>  - Update LATEST_MAJOR_VERSION in Versions.java
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - Merge branch 'master' into start-of-release-27
>>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>>  - Updates due to the generate-symbol-data.sh location changing in 8367259
>>  - Merge branch 'master' into start-of-release-27
>>  - update links to JVMS 26 and 27
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/a52f9076...78895b2b
>
> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
> 
>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>> 49: 
>> 50:     public static final int MAX_COLUMNS = 80;
> 
> I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.

oops.. that should have been `80x24`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566789434

From nbenalla at openjdk.org  Thu Nov 27 02:25:47 2025
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 27 Nov 2025 02:25:47 GMT
Subject: RFR: 8370890: Start of release updates for JDK 27 [v6]
In-Reply-To: <EZ6E_tH3VAGcKj7bcwIV08SJFx82vCibl-HDKki_sRY=.1ee06657-2d3e-441e-b991-96e5ce3b1b3b@github.com>
References: <M76mvRrS50M9dFtBQF9ipwBms42XzgHI9cUzg-esg6Y=.9f16d65d-7a9d-48ec-842c-fe7101ac8a70@github.com>
 <HENb5-p9uLm7E-FQj1CMHn6HbRsGMbcvfKOkz2B7Buk=.d77873f3-0f84-48fc-aed6-fdebba429f7a@github.com>
 <97FR4fTVW5KDQNoJ16P5pFYEvuMdhM3OjTX9lZF1xLo=.5a78ad27-3de5-46f7-818c-a3c14a0cb4a1@github.com>
 <EZ6E_tH3VAGcKj7bcwIV08SJFx82vCibl-HDKki_sRY=.1ee06657-2d3e-441e-b991-96e5ce3b1b3b@github.com>
Message-ID: <UpXYpfEPhm4i1vBqS1gz9G8gDd3YOXnh_5vCaBknMpA=.41bb620e-3db9-43a1-8c58-2e8711003476@github.com>

On Thu, 27 Nov 2025 00:35:11 GMT, Iris Clark <iris at openjdk.org> wrote:

>> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50:
>> 
>>> 48: public class HelpOutputColumnWidthTest extends TestRunner {
>>> 49: 
>>> 50:     public static final int MAX_COLUMNS = 80;
>> 
>> I though that the default terminal width was 24x80 in most systems, so 84 seems an odd choice.  I agree that 80 seems more appropriate.
>
> oops.. that should have been `80x24`.

I should have included more [context](https://github.com/openjdk/jdk/pull/25008#discussion_r2071880549).
The default width was increased to 84 in the last start of release update, I reverted it back to the original value.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2566979887

From dholmes at openjdk.org  Thu Nov 27 04:43:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Nov 2025 04:43:50 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time
In-Reply-To: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
Message-ID: <mSB952TPTu8yFAX6vCznGwKOF7adR_BkI-P0V7pkDXM=.99d0a382-3544-4475-a330-28f05274f4d4@github.com>

On Wed, 26 Nov 2025 22:43:26 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
> 
> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
> 
> 
> // Switch to using fast clocks for thread cpu time if
> // the sys_clock_getres() returns 0 error code.
> // Note, that some kernels may support the current thread
> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
> // returned by the pthread_getcpuclockid().
> // If the fast Posix clocks are supported then the sys_clock_getres()
> // must return at least tp.tv_sec == 0 which means a resolution
> // better than 1 sec. This is extra check for reliability.
> 
> 
> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
> 
> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.

The fast/slow to total/user renaming could be done as a first step to simplify the comparison as that isn't really removing unnecessary logic. And you didn't quite remove all the logic I expected to be removed.

Comments below. Thanks

src/hotspot/os/linux/os_linux.cpp line 162:

> 160: uintptr_t os::Linux::_initial_thread_stack_size   = 0;
> 161: 
> 162: int (*os::Linux::_pthread_getcpuclockid)(pthread_t, clockid_t *) = (int(*)(pthread_t, clockid_t *)) dlsym(RTLD_DEFAULT, "pthread_getcpuclockid");

I expected to see this go away. Are we not guaranteed to have the function available at build time and run time?

src/hotspot/os/linux/os_linux.cpp line 4955:

> 4953:                  &user_time, &sys_time);
> 4954:   if (count != 13) return -1;
> 4955:   return ((jlong)sys_time + (jlong)user_time) * (1000000000 / os::Posix::clock_tics_per_second());

If this function is meant to be `user` time you kept the wrong line.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28516#pullrequestreview-3513482225
PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2567110414
PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2567148791

From jnorlinder at openjdk.org  Thu Nov 27 06:49:47 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Thu, 27 Nov 2025 06:49:47 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time
In-Reply-To: <mSB952TPTu8yFAX6vCznGwKOF7adR_BkI-P0V7pkDXM=.99d0a382-3544-4475-a330-28f05274f4d4@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <mSB952TPTu8yFAX6vCznGwKOF7adR_BkI-P0V7pkDXM=.99d0a382-3544-4475-a330-28f05274f4d4@github.com>
Message-ID: <gPSK_nqc8UamBAb_c82OKrhFBWti8WYPIQf0rAYtDX4=.7dac5c20-84a1-4173-b83c-9238874212f9@github.com>

On Thu, 27 Nov 2025 04:04:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
>> 
>> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
>> 
>> 
>> // Switch to using fast clocks for thread cpu time if
>> // the sys_clock_getres() returns 0 error code.
>> // Note, that some kernels may support the current thread
>> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
>> // returned by the pthread_getcpuclockid().
>> // If the fast Posix clocks are supported then the sys_clock_getres()
>> // must return at least tp.tv_sec == 0 which means a resolution
>> // better than 1 sec. This is extra check for reliability.
>> 
>> 
>> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
>> 
>> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.
>
> src/hotspot/os/linux/os_linux.cpp line 162:
> 
>> 160: uintptr_t os::Linux::_initial_thread_stack_size   = 0;
>> 161: 
>> 162: int (*os::Linux::_pthread_getcpuclockid)(pthread_t, clockid_t *) = (int(*)(pthread_t, clockid_t *)) dlsym(RTLD_DEFAULT, "pthread_getcpuclockid");
> 
> I expected to see this go away. Are we not guaranteed to have the function available at build time and run time?

Thanks good point!

> src/hotspot/os/linux/os_linux.cpp line 4955:
> 
>> 4953:                  &user_time, &sys_time);
>> 4954:   if (count != 13) return -1;
>> 4955:   return ((jlong)sys_time + (jlong)user_time) * (1000000000 / os::Posix::clock_tics_per_second());
> 
> If this function is meant to be `user` time you kept the wrong line.

It returns the user_time variable. Could you please elaborate why that is wrong?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2567349819
PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2567345303

From jnorlinder at openjdk.org  Thu Nov 27 06:49:49 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Thu, 27 Nov 2025 06:49:49 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time
In-Reply-To: <gPSK_nqc8UamBAb_c82OKrhFBWti8WYPIQf0rAYtDX4=.7dac5c20-84a1-4173-b83c-9238874212f9@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <mSB952TPTu8yFAX6vCznGwKOF7adR_BkI-P0V7pkDXM=.99d0a382-3544-4475-a330-28f05274f4d4@github.com>
 <gPSK_nqc8UamBAb_c82OKrhFBWti8WYPIQf0rAYtDX4=.7dac5c20-84a1-4173-b83c-9238874212f9@github.com>
Message-ID: <WkFw5Wu3gNZIiMbReOaG4rVSeFMB8IC6rnQgoqPAOr4=.a81ab83f-3203-4bfd-8db7-6ddbdfd0f627@github.com>

On Thu, 27 Nov 2025 06:44:13 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 4955:
>> 
>>> 4953:                  &user_time, &sys_time);
>>> 4954:   if (count != 13) return -1;
>>> 4955:   return ((jlong)sys_time + (jlong)user_time) * (1000000000 / os::Posix::clock_tics_per_second());
>> 
>> If this function is meant to be `user` time you kept the wrong line.
>
> It returns the user_time variable. Could you please elaborate why that is wrong?

Oh I see now...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2567349205

From jnorlinder at openjdk.org  Thu Nov 27 07:06:31 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Thu, 27 Nov 2025 07:06:31 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v2]
In-Reply-To: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
Message-ID: <gtLydOOdX45y2ppkyP4l2eaJg4IZ9O8d1YLlJLWf5J8=.a771e4c9-c143-4b73-8f66-f31ab4b50aea@github.com>

> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
> 
> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
> 
> 
> // Switch to using fast clocks for thread cpu time if
> // the sys_clock_getres() returns 0 error code.
> // Note, that some kernels may support the current thread
> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
> // returned by the pthread_getcpuclockid().
> // If the fast Posix clocks are supported then the sys_clock_getres()
> // must return at least tp.tv_sec == 0 which means a resolution
> // better than 1 sec. This is extra check for reliability.
> 
> 
> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
> 
> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Remove dlsym and fix to correct return statement

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28516/files
  - new: https://git.openjdk.org/jdk/pull/28516/files/36934858..558b492d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28516&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28516&range=00-01

  Stats: 9 lines in 2 files changed: 0 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28516/head:pull/28516

PR: https://git.openjdk.org/jdk/pull/28516

From dholmes at openjdk.org  Thu Nov 27 08:00:49 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 27 Nov 2025 08:00:49 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v2]
In-Reply-To: <gtLydOOdX45y2ppkyP4l2eaJg4IZ9O8d1YLlJLWf5J8=.a771e4c9-c143-4b73-8f66-f31ab4b50aea@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <gtLydOOdX45y2ppkyP4l2eaJg4IZ9O8d1YLlJLWf5J8=.a771e4c9-c143-4b73-8f66-f31ab4b50aea@github.com>
Message-ID: <kBupshD-cUUOOV4M8usQ-7yJt0oMQuZYKQCCW49qaRI=.8e8848b4-9797-43c5-ad59-1035bdec4a2c@github.com>

On Thu, 27 Nov 2025 07:06:31 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
>> 
>> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
>> 
>> 
>> // Switch to using fast clocks for thread cpu time if
>> // the sys_clock_getres() returns 0 error code.
>> // Note, that some kernels may support the current thread
>> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
>> // returned by the pthread_getcpuclockid().
>> // If the fast Posix clocks are supported then the sys_clock_getres()
>> // must return at least tp.tv_sec == 0 which means a resolution
>> // better than 1 sec. This is extra check for reliability.
>> 
>> 
>> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
>> 
>> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dlsym and fix to correct return statement

Looks good! Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28516#pullrequestreview-3513924414

From mgronlun at openjdk.org  Thu Nov 27 10:34:26 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 27 Nov 2025 10:34:26 GMT
Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for
 class loading [v5]
In-Reply-To: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
References: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
Message-ID: <JLnHMXQq7j-RjxYP8YLID4tG5GFM7-i71WcYo71R4WQ=.08af34ec-d37c-4d63-9a7a-1e27487737b1@github.com>

> Greetings,
> 
> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
> 
> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
> 
> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
> 
> Testing: jdk_jfr, manual AOT verification, stress testing
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  remove

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28505/files
  - new: https://git.openjdk.org/jdk/pull/28505/files/d312adba..2e8809b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=03-04

  Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505

PR: https://git.openjdk.org/jdk/pull/28505

From coleenp at openjdk.org  Thu Nov 27 13:40:44 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Nov 2025 13:40:44 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v7]
In-Reply-To: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
Message-ID: <ghypcd9mX6KRp9KRHspxfYYlo81D_iO-yPNjlrkUhVg=.fa4889be-3aff-4d59-883e-9b71a5bcf6f1@github.com>

> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
> 
> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
> 
> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
> 
> Tested with submitted reproducer and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/classfile/systemDictionary.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28438/files
  - new: https://git.openjdk.org/jdk/pull/28438/files/a9f4e7f0..b23f907c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28438&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28438/head:pull/28438

PR: https://git.openjdk.org/jdk/pull/28438

From coleenp at openjdk.org  Thu Nov 27 13:40:48 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Nov 2025 13:40:48 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v6]
In-Reply-To: <R2jugSN2iPPOseR_z1XdPvCk3wiXHMy90mWl2VK_uzY=.85d46ab8-8fd5-4ca7-ad84-6dfe1b74fec6@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <R2jugSN2iPPOseR_z1XdPvCk3wiXHMy90mWl2VK_uzY=.85d46ab8-8fd5-4ca7-ad84-6dfe1b74fec6@github.com>
Message-ID: <KeYbSBQ2iIIbFavC5FYuYXjuow7AbdGBzNJKPile-rQ=.7377e819-f1c5-4362-88f3-54d131120c37@github.com>

On Wed, 26 Nov 2025 23:28:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/classfile/systemDictionary.cpp
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/share/classfile/systemDictionary.cpp line 1868:

> 1866:     ResolutionErrorEntry* entry = ResolutionErrorTable::find_entry(pool, which);
> 1867:     if (entry == nullptr) {
> 1868:       // Only add a new entry to the resolution error table if one hasn't been found for this 

Suggestion:

      // Only add a new entry to the resolution error table if one hasn't been found for this

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28438#discussion_r2568717797

From sjohanss at openjdk.org  Thu Nov 27 14:01:57 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 27 Nov 2025 14:01:57 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v2]
In-Reply-To: <gtLydOOdX45y2ppkyP4l2eaJg4IZ9O8d1YLlJLWf5J8=.a771e4c9-c143-4b73-8f66-f31ab4b50aea@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <gtLydOOdX45y2ppkyP4l2eaJg4IZ9O8d1YLlJLWf5J8=.a771e4c9-c143-4b73-8f66-f31ab4b50aea@github.com>
Message-ID: <bEcV17S7AIXg69gSZiW89IlmCmPWNjOc9cbuRo0mVmc=.21a96c98-331a-42ec-8027-d63550a70e41@github.com>

On Thu, 27 Nov 2025 07:06:31 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
>> 
>> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
>> 
>> 
>> // Switch to using fast clocks for thread cpu time if
>> // the sys_clock_getres() returns 0 error code.
>> // Note, that some kernels may support the current thread
>> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
>> // returned by the pthread_getcpuclockid().
>> // If the fast Posix clocks are supported then the sys_clock_getres()
>> // must return at least tp.tv_sec == 0 which means a resolution
>> // better than 1 sec. This is extra check for reliability.
>> 
>> 
>> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
>> 
>> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove dlsym and fix to correct return statement

I think the change looks good. Just a couple of small things that I would like you to fix before integrating.

Found this code in `cpuTimeCounters.cpp`, the comment is no longer correct and can probably be completely removed. Think it makes sense to do it in this change since we now have renamed `fast_thread_cpu_time()` to `total_thread_cpu_time()`:

void ThreadTotalCPUTimeClosure::do_thread(Thread* thread) {
  // The default code path (fast_thread_cpu_time()) asserts that
  // pthread_getcpuclockid() and clock_gettime() must return 0. Thus caller
  // must ensure the thread exists and has not terminated.
  _total += os::thread_cpu_time(thread);
}

src/hotspot/os/linux/os_linux.cpp line 4954:

> 4952:                  &user_time, &sys_time);
> 4953:   if (count != 13) return -1;
> 4954:   return (jlong)user_time * (1000000000 / os::Posix::clock_tics_per_second());

Please add an additional newline here for readability:
Suggestion:

  
  return (jlong)user_time * (1000000000 / os::Posix::clock_tics_per_second());

-------------

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28516#pullrequestreview-3515467117
PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2568767743

From jnorlinder at openjdk.org  Thu Nov 27 14:28:33 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Thu, 27 Nov 2025 14:28:33 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v3]
In-Reply-To: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
Message-ID: <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>

> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
> 
> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
> 
> 
> // Switch to using fast clocks for thread cpu time if
> // the sys_clock_getres() returns 0 error code.
> // Note, that some kernels may support the current thread
> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
> // returned by the pthread_getcpuclockid().
> // If the fast Posix clocks are supported then the sys_clock_getres()
> // must return at least tp.tv_sec == 0 which means a resolution
> // better than 1 sec. This is extra check for reliability.
> 
> 
> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
> 
> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  kstefanj review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28516/files
  - new: https://git.openjdk.org/jdk/pull/28516/files/558b492d..c23387e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28516&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28516&range=01-02

  Stats: 4 lines in 2 files changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28516.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28516/head:pull/28516

PR: https://git.openjdk.org/jdk/pull/28516

From sjohanss at openjdk.org  Thu Nov 27 14:33:52 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Thu, 27 Nov 2025 14:33:52 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v3]
In-Reply-To: <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>
Message-ID: <4UvjCOdB9PiJadQUI37KF_bR92lpG1DeyU_dGcNMrUM=.3bd0efa0-7fac-4050-8d3c-b7c449ece924@github.com>

On Thu, 27 Nov 2025 14:28:33 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
>> 
>> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
>> 
>> 
>> // Switch to using fast clocks for thread cpu time if
>> // the sys_clock_getres() returns 0 error code.
>> // Note, that some kernels may support the current thread
>> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
>> // returned by the pthread_getcpuclockid().
>> // If the fast Posix clocks are supported then the sys_clock_getres()
>> // must return at least tp.tv_sec == 0 which means a resolution
>> // better than 1 sec. This is extra check for reliability.
>> 
>> 
>> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
>> 
>> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kstefanj review comments

Marked as reviewed by sjohanss (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28516#pullrequestreview-3515728236

From duke at openjdk.org  Thu Nov 27 14:33:52 2025
From: duke at openjdk.org (duke)
Date: Thu, 27 Nov 2025 14:33:52 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v3]
In-Reply-To: <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>
Message-ID: <FUZpydTcp2XLZo7mfW5PSIMqr_um6DmTPgA6iWoMVNM=.f7c9b62d-27b7-4ab7-be7c-0d7a9c8948fc@github.com>

On Thu, 27 Nov 2025 14:28:33 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
>> 
>> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
>> 
>> 
>> // Switch to using fast clocks for thread cpu time if
>> // the sys_clock_getres() returns 0 error code.
>> // Note, that some kernels may support the current thread
>> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
>> // returned by the pthread_getcpuclockid().
>> // If the fast Posix clocks are supported then the sys_clock_getres()
>> // must return at least tp.tv_sec == 0 which means a resolution
>> // better than 1 sec. This is extra check for reliability.
>> 
>> 
>> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
>> 
>> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kstefanj review comments

@JonasNorlinder 
Your change (at version c23387e230b0f1798f1baabac9ac9416782836d5) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28516#issuecomment-3586174219

From jnorlinder at openjdk.org  Thu Nov 27 15:01:59 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Thu, 27 Nov 2025 15:01:59 GMT
Subject: Integrated: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time
In-Reply-To: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
Message-ID: <fR_VDPOYc1GQY02UWcwdw0F7-lGhBvzFVmzxxl-6TO0=.640d2bc5-40b5-48b1-99dd-ec22c197f1f8@github.com>

On Wed, 26 Nov 2025 22:43:26 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
> 
> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
> 
> 
> // Switch to using fast clocks for thread cpu time if
> // the sys_clock_getres() returns 0 error code.
> // Note, that some kernels may support the current thread
> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
> // returned by the pthread_getcpuclockid().
> // If the fast Posix clocks are supported then the sys_clock_getres()
> // must return at least tp.tv_sec == 0 which means a resolution
> // better than 1 sec. This is extra check for reliability.
> 
> 
> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
> 
> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.

This pull request has now been integrated.

Changeset: 683ef14b
Author:    Jonas Norlinder <jnorlinder at openjdk.org>
Committer: Stefan Johansson <sjohanss at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/683ef14bcec0e6c4825067229826ed4a53cd3d19
Stats:     75 lines in 3 files changed: 0 ins; 58 del; 17 mod

8372625: [Linux] Remove unnecessary logic for supports_fast_thread_cpu_time

Reviewed-by: sjohanss, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/28516

From liach at openjdk.org  Thu Nov 27 16:27:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 16:27:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <uuPHSGfRVckl3j5nRrikwU5eTwVjMhRrgiqB2RxKZBk=.91ecc1c8-cbed-45fb-be56-7900f23fc1ac@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

This uses another one of the 16-bit instanceKlassFlags, which requires runtime engineers to agree. Need compiler review to check if such IR tests are the best way to ensure constant folding for core library classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3586679853

From jvernee at openjdk.org  Thu Nov 27 16:50:48 2025
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 27 Nov 2025 16:50:48 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <0f6w-e-F6PVzyBNmFsu37oNVKgKSxNwQMfA1Y2GC46c=.d196d665-deeb-432c-b089-a4f5494b44ec@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3516377492

From alanb at openjdk.org  Thu Nov 27 18:50:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Nov 2025 18:50:47 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

src/hotspot/share/ci/ciField.cpp line 220:

> 218:     return false;
> 219:   // Explicit opt-in from system classes
> 220:   if (holder->trust_final_fields())

This is definitely nicer than listing specific classes. It would be nicer again once we can make this exceptions go away.

src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 61:

> 59: /// fields in classes specified by this annotation.
> 60: ///
> 61: /// This annotation is only recognized on privileged code and is ignored elsewhere.

"privileged code" hints of protection domains, permissions or security manager. Some of the annotations are limited to classes defined by the boot loader, is it the case here too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569767299
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569764340

From liach at openjdk.org  Thu Nov 27 19:01:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 19:01:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
Message-ID: <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>

On Thu, 27 Nov 2025 18:45:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 61:
> 
>> 59: /// fields in classes specified by this annotation.
>> 60: ///
>> 61: /// This annotation is only recognized on privileged code and is ignored elsewhere.
> 
> "privileged code" hints of protection domains, permissions or security manager. Some of the annotations are limited to classes defined by the boot loader, is it the case here too?

I took this sentence from `@AOTSafeClassInitializer`.  The term "privileged" comes from this variable in `classFileParser.cpp`:
https://github.com/openjdk/jdk/blob/d94c52ccf2fed3fc66d25a34254c9b581c175fa1/src/hotspot/share/classfile/classFileParser.cpp#L1818-L1820

The other annotations have this note, which seems incorrect from the hotspot excerpt:

@implNote
This annotation only takes effect for fields of classes loaded by the boot
loader.  Annotations on fields of classes loaded outside of the boot loader
are ignored.


This behavior seems to be originally changed by 6964a690ed9a23d4c0692da2dfbced46e1436355, referring to an inaccessible issue.

What should I do with this? Should I leave this as-is and create a separate patch to update this comment for vm.annotation annotations, or fix this first and have the separate patch fix other annotations later?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569787223

From liach at openjdk.org  Thu Nov 27 19:11:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 27 Nov 2025 19:11:47 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
Message-ID: <JWIrmuux-_o4Pl4YXYfPWqxceoGdi_8s8ynrp3aXgJw=.ccbf84bf-242f-4bc8-a06b-55e3fac41b7a@github.com>

On Thu, 27 Nov 2025 18:47:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> src/hotspot/share/ci/ciField.cpp line 220:
> 
>> 218:     return false;
>> 219:   // Explicit opt-in from system classes
>> 220:   if (holder->trust_final_fields())
> 
> This is definitely nicer than listing specific classes. It would be nicer again once we can make this exceptions go away.

True, this occupies one of the 16 precious instance klass bits in runtime. I wish we can derive this from our final means final restrictions, but their setup is to permit use-sites to migrate more easily, and is harder for declaration sites to deduce if a declaration is easier to be permitted. We can consider blanket-trust when the JVM uses `--illegal-final-field-mutation=deny` without additional `--enable-final-field-mutation`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2569800720

From mgronlun at openjdk.org  Thu Nov 27 19:21:33 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 27 Nov 2025 19:21:33 GMT
Subject: RFR: 8365400: Enhance JFR to emit file and module metadata for
 class loading [v6]
In-Reply-To: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
References: <GdhWHZhomFQs19oFkwcZhEYcS6BDIXIX9p1d5hI_w9g=.3aea7d5c-ebc1-429c-97d2-ca26408590a9@github.com>
Message-ID: <krhJ4oVxXW36DX7D6bL5Sw73e88T4B0k7Cyeyaf4nlM=.d0d380e5-8a5d-4a65-844f-8b465962c8bc@github.com>

> Greetings,
> 
> this enhancement adds a "source" field, label "Location" to the jdk.ClassDefine event.
> 
> To enable this functionality, JFR needs a concurrent symbol table. We can build a simpler version of a concurrent hash table, taking advantage of the JFR epoch system. This will be useful also for planned future enhancements.
> 
> Extensions are made to AOT to consistently report identical canonical paths for classes as non-AOT code paths.
> 
> Testing: jdk_jfr, manual AOT verification, stress testing
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  jfr views for class source

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28505/files
  - new: https://git.openjdk.org/jdk/pull/28505/files/2e8809b0..c0e1124e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28505&range=04-05

  Stats: 26 lines in 3 files changed: 21 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28505/head:pull/28505

PR: https://git.openjdk.org/jdk/pull/28505

From dholmes at openjdk.org  Fri Nov 28 02:34:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Nov 2025 02:34:57 GMT
Subject: RFR: 8365526: Crash with null Symbol passed to
 SystemDictionary::resolve_or_null [v7]
In-Reply-To: <ghypcd9mX6KRp9KRHspxfYYlo81D_iO-yPNjlrkUhVg=.fa4889be-3aff-4d59-883e-9b71a5bcf6f1@github.com>
References: <xBcmM6LHCgBl3nGbFdJ9FtVk5tAihat-PprASw9B0RY=.b90d6b4c-8559-4bfa-9d39-b6888e7fa4d8@github.com>
 <ghypcd9mX6KRp9KRHspxfYYlo81D_iO-yPNjlrkUhVg=.fa4889be-3aff-4d59-883e-9b71a5bcf6f1@github.com>
Message-ID: <6LE4zi7Q-HIu-qM2vDlTIiegRkwrBNrVemBBTtBr-rs=.e4cf2dfd-5bb5-4a59-921f-1546bde12985@github.com>

On Thu, 27 Nov 2025 13:40:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The vm was crashing because the constant pool couldn't find the resolution error in the ResolutionErrorEntry error field.
>> 
>> There are two uses of ResolutionErrorEntry in the ResolutionErrorTable.  The key to this table is {ConstantPool, cp-index}.   In this crash, multiple threads were racing to record nest_host_errors in the case where resolution failed.  In this case, there was already a ResolutionErrorEntry in the table for the constant pool resolution failure.  In the 'if' case of add_nest_host_error we check to see if there's already a nest_host_error assuming it's the same error, then the 'else' case was unconditionally adding a ResolutionErrorEntry with just the nest host message.  Calling HashTable::put() with this entry with just the nest host message, was overwriting the entry with the constant pool resolution error, ie. the other fields.  The crash happened in ConstantPool::throw_resolution_error() because the error field was overwritten (and leaked too).
>> 
>> Add a null check before calling ResolutionErrorEntry add entry.  Also added an assert that we only add a resolution error for nest host errors in the case of success since in the case of failure there will always already be a ResolutionErrorEntry for the failing constant pool and cp index and we don't want to overwrite that again.
>> 
>> Tested with submitted reproducer and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/classfile/systemDictionary.cpp

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28438#pullrequestreview-3517298459

From dholmes at openjdk.org  Fri Nov 28 02:41:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Nov 2025 02:41:06 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v3]
In-Reply-To: <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>
Message-ID: <B9iMKSk_TnpOIrrD9XWWxjoFAapFGzE3dKqjJinXzZ4=.dbe670b9-9754-4302-a13c-f9893919fb3b@github.com>

On Thu, 27 Nov 2025 14:28:33 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> For Linux we test if we can use `CLOCK_THREAD_CPUTIME_ID` but not the clocks supported by `pthread_getcpuclockid()`.
>> 
>> The following comment has been around for at least 18 years according to the git commit history (points to the initial git commit from Dec 1, 2007):
>> 
>> 
>> // Switch to using fast clocks for thread cpu time if
>> // the sys_clock_getres() returns 0 error code.
>> // Note, that some kernels may support the current thread
>> // clock (CLOCK_THREAD_CPUTIME_ID) but not the clocks
>> // returned by the pthread_getcpuclockid().
>> // If the fast Posix clocks are supported then the sys_clock_getres()
>> // must return at least tp.tv_sec == 0 which means a resolution
>> // better than 1 sec. This is extra check for reliability.
>> 
>> 
>> There was a time when the Linux kernel did not provide an implementation for `CLOCK_THREAD_CPUTIME_ID` (that arrived with v2.6.12). During this period, glibc emulated support for `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` in userspace for the current thread only. `clock_gettime(CLOCK_THREAD_CPUTIME_ID)` will call `pthread_getcpuclockid` in https://elixir.bootlin.com/glibc/glibc-2.2.5/source/linuxthreads/sysdeps/pthread/getcpuclockid.c. The checks and comment exists because `CLOCK_THREAD_CPUTIME_ID` worked (via emulation) but `pthread_getcpuclockid()` failed. 
>> 
>> During that period of the early 2000s this check was indeed needed. But now sufficient time has passed and we don't support OpenJDK for that old kernel versions/glibc. Therefore, this check should be removed and some code can be cleaned up.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   kstefanj review comments

src/hotspot/share/runtime/cpuTimeCounters.cpp line 123:

> 121:   // The default code path (fast_thread_cpu_time()) asserts that
> 122:   // pthread_getcpuclockid() and clock_gettime() must return 0. Thus caller
> 123:   // must ensure the thread exists and has not terminated.

I think the part about ensuring the thread exists and has not terminated still applies.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2570315534

From duke at openjdk.org  Fri Nov 28 08:30:09 2025
From: duke at openjdk.org (duke)
Date: Fri, 28 Nov 2025 08:30:09 GMT
Subject: Withdrawn: 8367984: Eliminate offset_of in vmStructs
In-Reply-To: <gMl5FcF4pRnK2Rqzwu-9SiHgqGXQpCPm-Sd9dQO35m4=.2217b178-8e68-4352-806f-f13950078d2f@github.com>
References: <gMl5FcF4pRnK2Rqzwu-9SiHgqGXQpCPm-Sd9dQO35m4=.2217b178-8e68-4352-806f-f13950078d2f@github.com>
Message-ID: <UNO7RnE0FhDFv_w6LgvYe8WHSKK2HfrheNHYAQI5bTY=.c3e29a31-09ff-4bac-9e2a-e2cd5b5cbbe8@github.com>

On Thu, 18 Sep 2025 12:44:27 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> There are several usages of `offset_of` in `vmStructs`, they can be replaced with standard `offsetof` due to [JDK-8367016](https://bugs.openjdk.org/browse/JDK-8367016).
> 
> Passes `tier1`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27362

From jnorlinder at openjdk.org  Fri Nov 28 08:47:04 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 28 Nov 2025 08:47:04 GMT
Subject: RFR: 8372625: [Linux] Remove unnecessary logic for
 supports_fast_thread_cpu_time [v3]
In-Reply-To: <B9iMKSk_TnpOIrrD9XWWxjoFAapFGzE3dKqjJinXzZ4=.dbe670b9-9754-4302-a13c-f9893919fb3b@github.com>
References: <9iqwFFvMXirOgt1KuMFH0aPkCw5Spmbk30JGJUnE4Vs=.81dd01b3-2095-4ddc-afe7-a92b2a9c1fb2@github.com>
 <8rMy9sXKxePDdb6UhRnD3dycEhSRzlDkX4URJsIIejs=.16107243-162e-4c1e-a728-63b0062cff6e@github.com>
 <B9iMKSk_TnpOIrrD9XWWxjoFAapFGzE3dKqjJinXzZ4=.dbe670b9-9754-4302-a13c-f9893919fb3b@github.com>
Message-ID: <c07Fb7y_B9vOor8k2ErnX8H0VBv6Mp7pvVLkMDUDPB8=.86814f67-b7fb-4d27-9d1d-3e1dbc8e5dd8@github.com>

On Fri, 28 Nov 2025 02:37:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   kstefanj review comments
>
> src/hotspot/share/runtime/cpuTimeCounters.cpp line 123:
> 
>> 121:   // The default code path (fast_thread_cpu_time()) asserts that
>> 122:   // pthread_getcpuclockid() and clock_gettime() must return 0. Thus caller
>> 123:   // must ensure the thread exists and has not terminated.
> 
> I think the part about ensuring the thread exists and has not terminated still applies.

Yes it still applies but I'm not sure that this comment should be in this method. If we want to inform users about this assumption we should add a comment in `os` in my opinion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28516#discussion_r2570844294

From pminborg at openjdk.org  Fri Nov 28 09:03:49 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 28 Nov 2025 09:03:49 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <H19jbssyUOV56d0xYR4EHV6a4ZCYIA95yz_w5gZX--M=.afd0782d-56dd-4eca-b607-1b7f4813b440@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

I really like this one!

I wonder if we could enable the new annotation `@TrustFinalFields` on package level as well so we could get rid of _all_ the special handing in `ciField.spp`. I am not sure this is the best way to do it but it would perhaps be possible to annotate the `package-info.java` file. For example in `java.lang.invoke.package-info.java`:


@TrustFinalFields
package java.lang.invoke;


Is there a better way to do it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3588443540

From shade at openjdk.org  Fri Nov 28 10:37:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Nov 2025 10:37:49 GMT
Subject: RFR: 8371769: TestMemoryInvisibleParent.java fails
 java.nio.file.AccessDeniedException [v2]
In-Reply-To: <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com>
References: <zFcxfyZig1unRmDYC7AIRB5KOby3rrp6TAbAkXnp6z8=.6bbd6a2a-60e7-4d08-9e13-aaf8dca7dc43@github.com>
 <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com>
Message-ID: <XzVqx6DDGHiupjvMU3n_KA4QzdHh2bXwiVWH_Gh8oZo=.039ef640-6484-48b3-902b-429b76c4e499@github.com>

On Mon, 17 Nov 2025 02:45:45 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java fails when run with non-root user. Test will try to write file /sys/fs/cgroup/memory/hidden-parent-TestMemoryInvisibleParent26/memory.limit_in_bytes, and this will make non-root user report java.nio.file.AccessDeniedException. So I think we should skip this test when user is not root.
>> 
>> This PR also add prefix indent for a try block, but do not touch the original logic.
>> 
>> Change has been verified locally on linux-aarch64 with non-root user.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8371769
>  - 8371769: TestMemoryInvisibleParent.java fails java.nio.file.AccessDeniedException

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28286#pullrequestreview-3518397646

From sgehwolf at openjdk.org  Fri Nov 28 10:47:52 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 28 Nov 2025 10:47:52 GMT
Subject: RFR: 8371769: TestMemoryInvisibleParent.java fails
 java.nio.file.AccessDeniedException [v2]
In-Reply-To: <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com>
References: <zFcxfyZig1unRmDYC7AIRB5KOby3rrp6TAbAkXnp6z8=.6bbd6a2a-60e7-4d08-9e13-aaf8dca7dc43@github.com>
 <9mSQb3fSotVeBtYrpPo-4cqiTKgIwlvWQQUehF2pspE=.9d6fd8b7-8db1-4f67-921e-ba9bf27eb88d@github.com>
Message-ID: <icRXQ2Pj6OkTtapFaBIjI642qpRyxjO-gvXU1XrOIus=.5298ff4c-98b9-4765-90cf-8bed522b629b@github.com>

On Mon, 17 Nov 2025 02:45:45 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Test test/hotspot/jtreg/containers/docker/TestMemoryInvisibleParent.java fails when run with non-root user. Test will try to write file /sys/fs/cgroup/memory/hidden-parent-TestMemoryInvisibleParent26/memory.limit_in_bytes, and this will make non-root user report java.nio.file.AccessDeniedException. So I think we should skip this test when user is not root.
>> 
>> This PR also add prefix indent for a try block, but do not touch the original logic.
>> 
>> Change has been verified locally on linux-aarch64 with non-root user.
>
> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into jbs8371769
>  - 8371769: TestMemoryInvisibleParent.java fails java.nio.file.AccessDeniedException

FYI: Updated the summary on the bug. Please change the PR title accordingly before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28286#issuecomment-3588801176

From alanb at openjdk.org  Fri Nov 28 10:55:54 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 10:55:54 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
Message-ID: <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>

On Thu, 27 Nov 2025 18:58:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 61:
>> 
>>> 59: /// fields in classes specified by this annotation.
>>> 60: ///
>>> 61: /// This annotation is only recognized on privileged code and is ignored elsewhere.
>> 
>> "privileged code" hints of protection domains, permissions or security manager. Some of the annotations are limited to classes defined by the boot loader, is it the case here too?
>
> I took this sentence from `@AOTSafeClassInitializer`.  The term "privileged" comes from this variable in `classFileParser.cpp`:
> https://github.com/openjdk/jdk/blob/d94c52ccf2fed3fc66d25a34254c9b581c175fa1/src/hotspot/share/classfile/classFileParser.cpp#L1818-L1820
> 
> The other annotations have this note, which seems incorrect from the hotspot excerpt:
> 
> @implNote
> This annotation only takes effect for fields of classes loaded by the boot
> loader.  Annotations on fields of classes loaded outside of the boot loader
> are ignored.
> 
> 
> This behavior seems to be originally changed by 6964a690ed9a23d4c0692da2dfbced46e1436355, referring to an inaccessible issue.
> 
> What should I do with this? Should I leave this as-is and create a separate patch to update this comment for vm.annotation annotations, or fix this first and have the separate patch fix other annotations later?

For this PR then you could just change the last sentence to say that the annotation is only effective for classes defined by the boot class loader or platform class loader. A follow-up PR could propose changes to the other annotation descriptions.

As regards background then one of the significant changes in JDK 9 was that java.* modules could be mapped to the platform class loader without give them "all permission" in the security manager execution mode. If you see JBS issues or comments speaking of "de-privileging" then it's likely related to changes that "moved" modules that were originally mapped to the boot class loader to the platform class loader. Now that the security manager execution mode is gone then we don't have to deal with all these issues now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571257172

From alanb at openjdk.org  Fri Nov 28 10:59:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 10:59:48 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <JWIrmuux-_o4Pl4YXYfPWqxceoGdi_8s8ynrp3aXgJw=.ccbf84bf-242f-4bc8-a06b-55e3fac41b7a@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <JWIrmuux-_o4Pl4YXYfPWqxceoGdi_8s8ynrp3aXgJw=.ccbf84bf-242f-4bc8-a06b-55e3fac41b7a@github.com>
Message-ID: <Y3ZawicQrH0Cj6bG2XGSAUez9GTmkAIRiJWr3t9jPLU=.fbabc76f-3cf6-4d1a-9c48-68b2cbbeeee2@github.com>

On Thu, 27 Nov 2025 19:08:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/hotspot/share/ci/ciField.cpp line 220:
>> 
>>> 218:     return false;
>>> 219:   // Explicit opt-in from system classes
>>> 220:   if (holder->trust_final_fields())
>> 
>> This is definitely nicer than listing specific classes. It would be nicer again once we can make this exceptions go away.
>
> True, this occupies one of the 16 precious instance klass bits in runtime. I wish we can derive this from our final means final restrictions, but their setup is to permit use-sites to migrate more easily, and is harder for declaration sites to deduce if a declaration is easier to be permitted. We can consider blanket-trust when the JVM uses `--illegal-final-field-mutation=deny` without additional `--enable-final-field-mutation`.

This would be the equivalent of running with -XX:+TrustFinalNonStaticFields, which would be nice, but there would be performance surprises as soon as you enable final field mutation for any module (and likely ALL-UNNAMED).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571272623

From alanb at openjdk.org  Fri Nov 28 11:08:56 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 28 Nov 2025 11:08:56 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <H19jbssyUOV56d0xYR4EHV6a4ZCYIA95yz_w5gZX--M=.afd0782d-56dd-4eca-b607-1b7f4813b440@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <H19jbssyUOV56d0xYR4EHV6a4ZCYIA95yz_w5gZX--M=.afd0782d-56dd-4eca-b607-1b7f4813b440@github.com>
Message-ID: <27R9PsHG0Jn3Ov39a-G9IXvKoEG01P0mOKMfVVrF4S4=.82593db1-0844-428f-9eff-af1529ff9663@github.com>

On Fri, 28 Nov 2025 09:00:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> I wonder if we could enable the new annotation `@TrustFinalFields` on package level as well so we could get rid of _all_ the special handing in `ciField.spp`. I am not sure this is the best way to do it but it would perhaps be possible to annotate the `package-info.java` file. For example in `java.lang.invoke.package-info.java`:

The VM don't read/parse the package-info class. It's really only used from APIs to read the annotations. In any case, teh long term goal needs to be to remove all special handling.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3588887344

From fandreuzzi at openjdk.org  Fri Nov 28 11:53:56 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 28 Nov 2025 11:53:56 GMT
Subject: RFR: 8371587: Final mapping lost in ProcSmapsParser::parse_next
 [v2]
In-Reply-To: <NZDw7Ao9GFDHtxLbW7MTsQuWTrW-azjac9e318dQLVk=.fd95754e-e6b5-4068-bbd3-0658fe1f4b40@github.com>
References: <nCSdjRi9SqcR9RThn_F5DmK7peCliid5ZRXL2joRgQk=.8b72311c-435c-488b-ae5c-bebf241dd7b2@github.com>
 <NZDw7Ao9GFDHtxLbW7MTsQuWTrW-azjac9e318dQLVk=.fd95754e-e6b5-4068-bbd3-0658fe1f4b40@github.com>
Message-ID: <70PPBuixZ0kKUhuhBzt28AbiKoMn4BOiegbj_RDx1cg=.42fb8898-96d0-40e2-8644-84f655f26e64@github.com>

On Mon, 24 Nov 2025 14:29:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> A simple fix for off-by-one error in parsing `smaps` -- the final mapping is never recorded as we exits the parsing loop too early.
>> 
>> The spec of `parse_next` is updated to reflects what its caller expects. The newly added gtest fails without this path.
>> 
>> 
>> Test: tier1
>
> Albert Mingkun Yang 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 four additional commits since the last revision:
> 
>  - copyright-header
>  - review
>  - Merge branch 'master' into smap-parser
>  - smap-parser

When `fgets` fails due to an error, it returns `nullptr` so `read_line` (L119) will return `false`. If a mapping was parsed, `parse_next` returns `true`. The next call to `parse_next` will start with this check:
https://github.com/openjdk/jdk/blob/c179ccd5b4a06f94ebec44ed1d75e7339f40e383/src/hotspot/os/linux/procMapsParser.cpp#L110-L114

But according to the [docs](https://en.cppreference.com/w/c/io/fgets) for `fgets`, the content of the buffer will be indeterminate at this point (since the last call failed due to an error). If any rubbish happens to be there, we won't even call `read_line` and we'll just try to `scan_header_line`, which is probably not the correct behavior.

Am I missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28225#issuecomment-3589025841

From jnorlinder at openjdk.org  Fri Nov 28 12:10:38 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 28 Nov 2025 12:10:38 GMT
Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU
 time with clock_gettime
Message-ID: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>

Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc.  that utilities this bit pattern.

This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max).

Before patch:

Benchmark                  Mode      Cnt  Score    Error  Units
CPUTime.execute          sample  7506555  0.008 ?  0.001  ms/op
CPUTime.execute:p0.00    sample           0.008           ms/op
CPUTime.execute:p0.50    sample           0.008           ms/op
CPUTime.execute:p0.90    sample           0.008           ms/op
CPUTime.execute:p0.95    sample           0.008           ms/op
CPUTime.execute:p0.99    sample           0.012           ms/op
CPUTime.execute:p0.999   sample           0.015           ms/op
CPUTime.execute:p0.9999  sample           0.021           ms/op
CPUTime.execute:p1.00    sample           1.030           ms/op


After patch:

Benchmark                  Mode      Cnt   Score    Error  Units
CPUTime.execute          sample  8984189  ? 10??           ms/op
CPUTime.execute:p0.00    sample           ? 10??           ms/op
CPUTime.execute:p0.50    sample           ? 10??           ms/op
CPUTime.execute:p0.90    sample           ? 10??           ms/op
CPUTime.execute:p0.95    sample           ? 10??           ms/op
CPUTime.execute:p0.99    sample            0.001           ms/op
CPUTime.execute:p0.999   sample            0.001           ms/op
CPUTime.execute:p0.9999  sample            0.006           ms/op
CPUTime.execute:p1.00    sample            0.054           ms/op


Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark.

-------------

Commit messages:
 - Replace proc with fast Linux specific solution

Changes: https://git.openjdk.org/jdk/pull/28556/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372584
  Stats: 142 lines in 3 files changed: 88 ins; 42 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28556/head:pull/28556

PR: https://git.openjdk.org/jdk/pull/28556

From fandreuzzi at openjdk.org  Fri Nov 28 12:16:50 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 28 Nov 2025 12:16:50 GMT
Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU
 time with clock_gettime
In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
Message-ID: <lRP8PaQGS5zdqjrl9BLo6qqSjOsNIAmwRcQrYPfoUeo=.e4545529-5213-4487-b4ef-61157a5f2168@github.com>

On Fri, 28 Nov 2025 12:00:28 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc.  that utilities this bit pattern.
> 
> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max).
> 
> Before patch:
> 
> Benchmark                  Mode      Cnt  Score    Error  Units
> CPUTime.execute          sample  7506555  0.008 ?  0.001  ms/op
> CPUTime.execute:p0.00    sample           0.008           ms/op
> CPUTime.execute:p0.50    sample           0.008           ms/op
> CPUTime.execute:p0.90    sample           0.008           ms/op
> CPUTime.execute:p0.95    sample           0.008           ms/op
> CPUTime.execute:p0.99    sample           0.012           ms/op
> CPUTime.execute:p0.999   sample           0.015           ms/op
> CPUTime.execute:p0.9999  sample           0.021           ms/op
> CPUTime.execute:p1.00    sample           1.030           ms/op
> 
> 
> After patch:
> 
> Benchmark                  Mode      Cnt   Score    Error  Units
> CPUTime.execute          sample  8984189  ? 10??           ms/op
> CPUTime.execute:p0.00    sample           ? 10??           ms/op
> CPUTime.execute:p0.50    sample           ? 10??           ms/op
> CPUTime.execute:p0.90    sample           ? 10??           ms/op
> CPUTime.execute:p0.95    sample           ? 10??           ms/op
> CPUTime.execute:p0.99    sample            0.001           ms/op
> CPUTime.execute:p0.999   sample            0.001           ms/op
> CPUTime.execute:p0.9999  sample            0.006           ms/op
> CPUTime.execute:p1.00    sample            0.054           ms/op
> 
> 
> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark.

src/hotspot/os/linux/os_linux.cpp line 4964:

> 4962: // in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel
> 4963: // returning only user time. POSIX compliant implementations of pthread_getcpuclockid
> 4964: // for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED)

Is `that with` intended here? It would make sense to me to have just `with`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2571470863

From jnorlinder at openjdk.org  Fri Nov 28 13:10:49 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 28 Nov 2025 13:10:49 GMT
Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU
 time with clock_gettime
In-Reply-To: <lRP8PaQGS5zdqjrl9BLo6qqSjOsNIAmwRcQrYPfoUeo=.e4545529-5213-4487-b4ef-61157a5f2168@github.com>
References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
 <lRP8PaQGS5zdqjrl9BLo6qqSjOsNIAmwRcQrYPfoUeo=.e4545529-5213-4487-b4ef-61157a5f2168@github.com>
Message-ID: <RUN8EfhJ9exD_rcOabx2Yx-BsqGc4qDQ86uAq9va3qw=.dc4fc449-ca69-43a9-9bdb-c3b535d5d047@github.com>

On Fri, 28 Nov 2025 12:13:44 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc.  that utilities this bit pattern.
>> 
>> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max).
>> 
>> Before patch:
>> 
>> Benchmark                  Mode      Cnt  Score    Error  Units
>> CPUTime.execute          sample  7506555  0.008 ?  0.001  ms/op
>> CPUTime.execute:p0.00    sample           0.008           ms/op
>> CPUTime.execute:p0.50    sample           0.008           ms/op
>> CPUTime.execute:p0.90    sample           0.008           ms/op
>> CPUTime.execute:p0.95    sample           0.008           ms/op
>> CPUTime.execute:p0.99    sample           0.012           ms/op
>> CPUTime.execute:p0.999   sample           0.015           ms/op
>> CPUTime.execute:p0.9999  sample           0.021           ms/op
>> CPUTime.execute:p1.00    sample           1.030           ms/op
>> 
>> 
>> After patch:
>> 
>> Benchmark                  Mode      Cnt   Score    Error  Units
>> CPUTime.execute          sample  8984189  ? 10??           ms/op
>> CPUTime.execute:p0.00    sample           ? 10??           ms/op
>> CPUTime.execute:p0.50    sample           ? 10??           ms/op
>> CPUTime.execute:p0.90    sample           ? 10??           ms/op
>> CPUTime.execute:p0.95    sample           ? 10??           ms/op
>> CPUTime.execute:p0.99    sample            0.001           ms/op
>> CPUTime.execute:p0.999   sample            0.001           ms/op
>> CPUTime.execute:p0.9999  sample            0.006           ms/op
>> CPUTime.execute:p1.00    sample            0.054           ms/op
>> 
>> 
>> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark.
>
> src/hotspot/os/linux/os_linux.cpp line 4964:
> 
>> 4962: // in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel
>> 4963: // returning only user time. POSIX compliant implementations of pthread_getcpuclockid
>> 4964: // for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED)
> 
> Is `that with` intended here? It would make sense to me to have just `with`

Thanks! It should be "with".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2571646138

From jpai at openjdk.org  Fri Nov 28 13:32:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 13:32:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
 <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
Message-ID: <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>

On Fri, 28 Nov 2025 10:52:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I took this sentence from `@AOTSafeClassInitializer`.  The term "privileged" comes from this variable in `classFileParser.cpp`:
>> https://github.com/openjdk/jdk/blob/d94c52ccf2fed3fc66d25a34254c9b581c175fa1/src/hotspot/share/classfile/classFileParser.cpp#L1818-L1820
>> 
>> The other annotations have this note, which seems incorrect from the hotspot excerpt:
>> 
>> @implNote
>> This annotation only takes effect for fields of classes loaded by the boot
>> loader.  Annotations on fields of classes loaded outside of the boot loader
>> are ignored.
>> 
>> 
>> This behavior seems to be originally changed by 6964a690ed9a23d4c0692da2dfbced46e1436355, referring to an inaccessible issue.
>> 
>> What should I do with this? Should I leave this as-is and create a separate patch to update this comment for vm.annotation annotations, or fix this first and have the separate patch fix other annotations later?
>
> For this PR then you could just change the last sentence to say that the annotation is only effective for classes defined by the boot class loader or platform class loader. A follow-up PR could propose changes to the other annotation descriptions.
> 
> As regards background then one of the significant changes in JDK 9 was that java.* modules could be mapped to the platform class loader without give them "all permission" in the security manager execution mode. If you see JBS issues or comments speaking of "de-privileging" then it's likely related to changes that "moved" modules that were originally mapped to the boot class loader to the platform class loader. Now that the security manager execution mode is gone then we don't have to deal with all these issues now.

Hello Chen, should this annotation also mention what happens if a class annotated with `@TrustFinalFields` has any of its `final` fields updated? For example, `@Stable` has this to say about such unexpected updates:


...It is in general a bad idea to reset such
* variables to any other value, since compiled code might have folded
* an earlier stored value, and will never detect the reset value.


Are there any unexpected consequences of marking a class as `@TrustFinalFields` and having a `@Stable` on any of the final fields (for example an array):


@TrustedFinalFields
class JDKFooBar {
    private final String reallyFinal;

    @Stable
    private final int reallyFinalButAlsoStable;

    @Stable
    private final long[] finalAndStableArray;

}

Finally, would it still be recommended that a class annotated with `@TrustFinalFields` also have a final array field annoted with `@Stable` if that array field elements are initialized to a non-default value only once?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571701254

From jpai at openjdk.org  Fri Nov 28 13:38:47 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 13:38:47 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
 <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
 <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>
Message-ID: <VQLfnM7dV7vMvn4VLD-WKQ3gHsFEVsdxQz98iebILUc=.1ed7e9cc-2f03-4109-8fa5-be69f7e7482f@github.com>

On Fri, 28 Nov 2025 13:30:33 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> For this PR then you could just change the last sentence to say that the annotation is only effective for classes defined by the boot class loader or platform class loader. A follow-up PR could propose changes to the other annotation descriptions.
>> 
>> As regards background then one of the significant changes in JDK 9 was that java.* modules could be mapped to the platform class loader without give them "all permission" in the security manager execution mode. If you see JBS issues or comments speaking of "de-privileging" then it's likely related to changes that "moved" modules that were originally mapped to the boot class loader to the platform class loader. Now that the security manager execution mode is gone then we don't have to deal with all these issues now.
>
> Hello Chen, should this annotation also mention what happens if a class annotated with `@TrustFinalFields` has any of its `final` fields updated? For example, `@Stable` has this to say about such unexpected updates:
> 
> 
> ...It is in general a bad idea to reset such
> * variables to any other value, since compiled code might have folded
> * an earlier stored value, and will never detect the reset value.
> 
> 
> Are there any unexpected consequences of marking a class as `@TrustFinalFields` and having a `@Stable` on any of the final fields (for example an array):
> 
> 
> @TrustedFinalFields
> class JDKFooBar {
>     private final String reallyFinal;
> 
>     @Stable
>     private final int reallyFinalButAlsoStable;
> 
>     @Stable
>     private final long[] finalAndStableArray;
> 
> }
> 
> Finally, would it still be recommended that a class annotated with `@TrustFinalFields` also have a final array field annoted with `@Stable` if that array field elements are initialized to a non-default value only once?

One another question - if a class/interface is annotated with `@TargetFinalFields`, is that annotation only applicable to that specific class or would it also be applicable for any (final fields in) subclasses of that class or implementations of that interface (does the VM ignore this annotation on an interface, should it)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571717831

From jpai at openjdk.org  Fri Nov 28 13:47:48 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Nov 2025 13:47:48 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>

On Thu, 27 Nov 2025 16:16:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 49:

> 47: /// As a result, this should be used on classes where package-wide trusting is
> 48: /// not possible due to backward compatibility concerns, such as for `java.util`
> 49: /// classes.

Should this sentence be reworded? It's not clear what the backward compatible concerns (for `java.util` package) are. I think it might be better to leave out any backward compatibility part when explaining which classes to use this annotation on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571741641

From jnorlinder at openjdk.org  Fri Nov 28 14:43:23 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 28 Nov 2025 14:43:23 GMT
Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU
 time with clock_gettime [v2]
In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
Message-ID: <_FKFBJVSwgDJ2G1ImxSx2Gc4kFrvbSsQAacqxQ2z2cE=.4abc3341-3be3-4812-8cd7-95c493d17d84@github.com>

> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc.  that utilities this bit pattern.
> 
> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max).
> 
> Before patch:
> 
> Benchmark                  Mode      Cnt  Score    Error  Units
> CPUTime.execute          sample  7506555  0.008 ?  0.001  ms/op
> CPUTime.execute:p0.00    sample           0.008           ms/op
> CPUTime.execute:p0.50    sample           0.008           ms/op
> CPUTime.execute:p0.90    sample           0.008           ms/op
> CPUTime.execute:p0.95    sample           0.008           ms/op
> CPUTime.execute:p0.99    sample           0.012           ms/op
> CPUTime.execute:p0.999   sample           0.015           ms/op
> CPUTime.execute:p0.9999  sample           0.021           ms/op
> CPUTime.execute:p1.00    sample           1.030           ms/op
> 
> 
> After patch:
> 
> Benchmark                  Mode      Cnt   Score    Error  Units
> CPUTime.execute          sample  8984189  ? 10??           ms/op
> CPUTime.execute:p0.00    sample           ? 10??           ms/op
> CPUTime.execute:p0.50    sample           ? 10??           ms/op
> CPUTime.execute:p0.90    sample           ? 10??           ms/op
> CPUTime.execute:p0.95    sample           ? 10??           ms/op
> CPUTime.execute:p0.99    sample            0.001           ms/op
> CPUTime.execute:p0.999   sample            0.001           ms/op
> CPUTime.execute:p0.9999  sample            0.006           ms/op
> CPUTime.execute:p1.00    sample            0.054           ms/op
> 
> 
> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Add review fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28556/files
  - new: https://git.openjdk.org/jdk/pull/28556/files/b3b74d64..52b1c3ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28556/head:pull/28556

PR: https://git.openjdk.org/jdk/pull/28556

From liach at openjdk.org  Fri Nov 28 15:08:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Nov 2025 15:08:56 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
Message-ID: <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>

On Fri, 28 Nov 2025 13:45:19 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 49:
> 
>> 47: /// As a result, this should be used on classes where package-wide trusting is
>> 48: /// not possible due to backward compatibility concerns, such as for `java.util`
>> 49: /// classes.
> 
> Should this sentence be reworded? It's not clear what the backward compatible concerns (for `java.util` package) are. I think it might be better to leave out any backward compatibility part when explaining which classes to use this annotation on.

Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571941033

From liach at openjdk.org  Fri Nov 28 15:08:57 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 28 Nov 2025 15:08:57 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <VQLfnM7dV7vMvn4VLD-WKQ3gHsFEVsdxQz98iebILUc=.1ed7e9cc-2f03-4109-8fa5-be69f7e7482f@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <tO0u2WRLnzSi_lfWjg96HsxkPtvYqbop_y0T_CPqA6k=.10d4c037-a261-4093-b4c7-c24ec60da0ad@github.com>
 <1tazzYHm78XLDovV11RAQt2W-ujENi4b_frOa87Jv14=.45b6d8a1-cb76-49ac-8048-429916bc9c6c@github.com>
 <vONVXWSZOINQXWCvZYg586jCTw_jOAoAa7GXFPEsZs4=.bc363b57-bf0d-46b5-9975-a16184d73cd3@github.com>
 <iRETQJf1F3YXVglgIPRKaJLtlaKO25gFz_bnvFrE2jY=.9ac10abf-9f44-4bf2-978c-b7ac45d4edc6@github.com>
 <VQLfnM7dV7vMvn4VLD-WKQ3gHsFEVsdxQz98iebILUc=.1ed7e9cc-2f03-4109-8fa5-be69f7e7482f@github.com>
Message-ID: <khq0N0_Qo2ziTunmpLWt7pAP58w75SD6lpbh5nSziio=.d79e7764-a24c-47f2-aa97-0b2fd4bb3b50@github.com>

On Fri, 28 Nov 2025 13:35:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Hello Chen, should this annotation also mention what happens if a class annotated with `@TrustFinalFields` has any of its `final` fields updated? For example, `@Stable` has this to say about such unexpected updates:
>> 
>> 
>> ...It is in general a bad idea to reset such
>> * variables to any other value, since compiled code might have folded
>> * an earlier stored value, and will never detect the reset value.
>> 
>> 
>> Are there any unexpected consequences of marking a class as `@TrustFinalFields` and having a `@Stable` on any of the final fields (for example an array):
>> 
>> 
>> @TrustedFinalFields
>> class JDKFooBar {
>>     private final String reallyFinal;
>> 
>>     @Stable
>>     private final int reallyFinalButAlsoStable;
>> 
>>     @Stable
>>     private final long[] finalAndStableArray;
>> 
>> }
>> 
>> Finally, would it still be recommended that a class annotated with `@TrustFinalFields` also have a final array field annoted with `@Stable` if that array field elements are initialized to a non-default value only once?
>
> One another question - if a class/interface is annotated with `@TargetFinalFields`, is that annotation only applicable to that specific class or would it also be applicable for any (final fields in) subclasses of that class or implementations of that interface (does the VM ignore this annotation on an interface, should it)?

I don't think we should mention anything about updating final fields. If you use this field, you intend the fields not to get subsequently updated. Promising the behavior in this case only introduces more trouble and is meaningless for this annotation's readers. For inheritance, we can add a word or two.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2571939030

From fandreuzzi at openjdk.org  Fri Nov 28 15:16:49 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 28 Nov 2025 15:16:49 GMT
Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU
 time with clock_gettime [v2]
In-Reply-To: <_FKFBJVSwgDJ2G1ImxSx2Gc4kFrvbSsQAacqxQ2z2cE=.4abc3341-3be3-4812-8cd7-95c493d17d84@github.com>
References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
 <_FKFBJVSwgDJ2G1ImxSx2Gc4kFrvbSsQAacqxQ2z2cE=.4abc3341-3be3-4812-8cd7-95c493d17d84@github.com>
Message-ID: <mQUMxrhdYVrbVjxoWDs3XqtTnbd2cWutX7IgoSvjrnU=.7bcc155b-4034-4f86-932e-46c58ff4e20a@github.com>

On Fri, 28 Nov 2025 14:43:23 GMT, Jonas Norlinder <jnorlinder at openjdk.org> wrote:

>> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc.  that utilities this bit pattern.
>> 
>> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max).
>> 
>> Before patch:
>> 
>> Benchmark                  Mode      Cnt  Score    Error  Units
>> CPUTime.execute          sample  7506555  0.008 ?  0.001  ms/op
>> CPUTime.execute:p0.00    sample           0.008           ms/op
>> CPUTime.execute:p0.50    sample           0.008           ms/op
>> CPUTime.execute:p0.90    sample           0.008           ms/op
>> CPUTime.execute:p0.95    sample           0.008           ms/op
>> CPUTime.execute:p0.99    sample           0.012           ms/op
>> CPUTime.execute:p0.999   sample           0.015           ms/op
>> CPUTime.execute:p0.9999  sample           0.021           ms/op
>> CPUTime.execute:p1.00    sample           1.030           ms/op
>> 
>> 
>> After patch:
>> 
>> Benchmark                  Mode      Cnt   Score    Error  Units
>> CPUTime.execute          sample  8984189  ? 10??           ms/op
>> CPUTime.execute:p0.00    sample           ? 10??           ms/op
>> CPUTime.execute:p0.50    sample           ? 10??           ms/op
>> CPUTime.execute:p0.90    sample           ? 10??           ms/op
>> CPUTime.execute:p0.95    sample           ? 10??           ms/op
>> CPUTime.execute:p0.99    sample            0.001           ms/op
>> CPUTime.execute:p0.999   sample            0.001           ms/op
>> CPUTime.execute:p0.9999  sample            0.006           ms/op
>> CPUTime.execute:p1.00    sample            0.054           ms/op
>> 
>> 
>> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add review fixes

test/micro/org/openjdk/bench/vm/runtime/CPUTime.java line 40:

> 38: import org.openjdk.jmh.annotations.CompilerControl;
> 39: import org.openjdk.jmh.annotations.Fork;
> 40: import org.openjdk.jmh.annotations.Level;

Is this used somewhere? Same for `Setup` and some other imports in this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28556#discussion_r2571957705

From jnorlinder at openjdk.org  Fri Nov 28 15:54:24 2025
From: jnorlinder at openjdk.org (Jonas Norlinder)
Date: Fri, 28 Nov 2025 15:54:24 GMT
Subject: RFR: 8372584: [Linux]: Replace reading proc to get thread user CPU
 time with clock_gettime [v3]
In-Reply-To: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
References: <8_C402dOOb8Qq5-rSe-iUtE96BuMhxttlPcN4WgYFig=.aad6aad3-9490-471e-b9cb-6fa9b4c9235e@github.com>
Message-ID: <V7wUMPPDe8b0PVFfZONbPFwodLxA-dfcu_QYPO9B5sw=.9880e820-8191-4bbe-adc2-a9c8752e0cfc@github.com>

> Since kernel v2.6.12 the Linux ABI have had support for encoding the clock types in the last three bits. Setting bit to 001 (CPUCLOCK_VIRT) will result in the kernel returning only user time. POSIX compliant implementations of pthread_getcpuclockid for the Linux kernel defaults to construct a clockid that with 010 (CPUCLOCK_SCHED) set, which return system+user time, which is what the POSIX standard mandates, see POSIX.1-2024/IEEE Std 1003.1-2024 ?3.90. This patch joins the family of glibc, musl etc.  that utilities this bit pattern.
> 
> This PR also results in improved performance and thus a reduced observer effect, especially for the 100th percentile (max).
> 
> Before patch:
> 
> Benchmark                  Mode      Cnt  Score    Error  Units
> CPUTime.execute          sample  7506555  0.008 ?  0.001  ms/op
> CPUTime.execute:p0.00    sample           0.008           ms/op
> CPUTime.execute:p0.50    sample           0.008           ms/op
> CPUTime.execute:p0.90    sample           0.008           ms/op
> CPUTime.execute:p0.95    sample           0.008           ms/op
> CPUTime.execute:p0.99    sample           0.012           ms/op
> CPUTime.execute:p0.999   sample           0.015           ms/op
> CPUTime.execute:p0.9999  sample           0.021           ms/op
> CPUTime.execute:p1.00    sample           1.030           ms/op
> 
> 
> After patch:
> 
> Benchmark                  Mode      Cnt   Score    Error  Units
> CPUTime.execute          sample  8984189  ? 10??           ms/op
> CPUTime.execute:p0.00    sample           ? 10??           ms/op
> CPUTime.execute:p0.50    sample           ? 10??           ms/op
> CPUTime.execute:p0.90    sample           ? 10??           ms/op
> CPUTime.execute:p0.95    sample           ? 10??           ms/op
> CPUTime.execute:p0.99    sample            0.001           ms/op
> CPUTime.execute:p0.999   sample            0.001           ms/op
> CPUTime.execute:p0.9999  sample            0.006           ms/op
> CPUTime.execute:p1.00    sample            0.054           ms/op
> 
> 
> Testing: `java/lang/management/ThreadMXBean/ThreadUserTime.java` and the added microbenchmark.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28556/files
  - new: https://git.openjdk.org/jdk/pull/28556/files/52b1c3ab..c022266d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28556&range=01-02

  Stats: 11 lines in 1 file changed: 0 ins; 11 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28556/head:pull/28556

PR: https://git.openjdk.org/jdk/pull/28556

From lucy at openjdk.org  Fri Nov 28 17:39:48 2025
From: lucy at openjdk.org (Lutz Schmidt)
Date: Fri, 28 Nov 2025 17:39:48 GMT
Subject: RFR: 8372272: Hotspot shared lib loading - add load attempts to
 Events::log
In-Reply-To: <aJLfOoDzKX7Eb9fjLfbrF-8qBjcvNBYvKj3xU20TJtA=.2d3731a6-e8a5-4ef9-9d2e-eb22c85f8a03@github.com>
References: <aJLfOoDzKX7Eb9fjLfbrF-8qBjcvNBYvKj3xU20TJtA=.2d3731a6-e8a5-4ef9-9d2e-eb22c85f8a03@github.com>
Message-ID: <pSwsssUENUuvsNkhdaUc-rrpEUwlVj-kUNEaCNBotbo=.90770b99-5016-4dcd-97a2-84322c702999@github.com>

On Fri, 21 Nov 2025 13:03:23 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Currently we log only the success or failure of shared lib load operations in HS
> (by calling Events::log_dll_message).
> Adding log messages for load attempts would help us in a number of cases :
> - give timestamps before AND after the load operation
> - log in hs_err file shared lib loads leading to crashes (there we do not see currently the success or failure of the dlopen operation)

Looks good as far as new code is concerned. 

Is it by intention that on windows the action is logged twice (log_info and Events::log_dll_message)?

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28452#pullrequestreview-3519617053

From jpai at openjdk.org  Sat Nov 29 07:12:53 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Nov 2025 07:12:53 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting
In-Reply-To: <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
Message-ID: <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>

On Fri, 28 Nov 2025 15:06:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/TrustFinalFields.java line 49:
>> 
>>> 47: /// As a result, this should be used on classes where package-wide trusting is
>>> 48: /// not possible due to backward compatibility concerns, such as for `java.util`
>>> 49: /// classes.
>> 
>> Should this sentence be reworded? It's not clear what the backward compatible concerns (for `java.util` package) are. I think it might be better to leave out any backward compatibility part when explaining which classes to use this annotation on.
>
> Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

Hello Chen,

> because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

This is one of the reasons why I asked some of the questions that I did. We have seen several PRs in the recent past where `@Stable` annotation has been introduced in the core classes of Java SE because it aids constant folding optimizations. Most of those changes have been backed merely by JMH benchmarks. It won't be a surprise if we start seeing another round of PRs where the usage of this new `@TrustFinalFields` gets proposed to some of these classes in the JDK because it shows an improvement in some micro benchmark. It also won't be a surprise if those PRs too won't have associated regression tests. Furthermore, unlike `@Stable` which gets applied directly on the field(s) of interest, this new annotation will be applied a bit "far away" from such fields. So it will need additional review cycles to understand if this usage can impact the code functionally in any manner. Specifying the semantics of this annotation in various usage scenarios, in its javadoc, will aid in reviewing su
 ch changes in future, instead of having to regularly look into the JVM code to understand how this annotation behaves.

Classes in `java.util` aren't special in any way. So if applications are changing the values of final fields of some of those classes, then the same would be done for other packages of Java SE APIs too. If, like you note, applying `@TrustFinalFields` on such classes is going to break applications, then it will be useful to specify what kind of breakages those will be (in a similar manner to what the `@Stable` annotation's javadoc does).

Very specifically, I think adding a few sentences clarifying the following scenarios in this annotation's javadoc will be useful:

- Will this annotation be honoured only on the specific class that it is applied to? Or will it be taken into consideration for final fields in subclasses too? 
- If this annotation gets applied on a class and if that class has some final fields which are already marked `@Stable`, what kind of implications will that have, if any?
- If this annotation is marked on a class which has a `final` array field (for example `final long[] ids`), is it useful to continue placing a `@Stable` annotation on such array fields if the elements of those arrays are going to be initialized to a non-default value just once?
- If after all the precautions are taken, if the final field of a class annotated with `@TrustFinalFields` does get updated to a new value, what kind of impact would it have (stating that such behaviour is unspecified and in general is a bad idea would be enough, if that's all there is to it)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2572850670

From kbarrett at openjdk.org  Sat Nov 29 10:27:25 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 29 Nov 2025 10:27:25 GMT
Subject: RFR: 8372755: Remove local suppression of VS C4146 warnings
Message-ID: <Qy1VlJBpgxVIIZ0x6ILJMIDV8XAtISfZvhSNN8rwYhg=.595fad5a-18e1-49bf-b582-5418375a60cc@github.com>

Please review this trivial change to remove unnecessary local Visual Studio
warning suppressions for C4146 in HotSpot code.  JDK-8254072 intentionally
globally suppressed that warning when building HotSpot, so local suppression
is no longer needed.

Testing: mach5 tier1

-------------

Commit messages:
 - remove local suppression of VS C4146

Changes: https://git.openjdk.org/jdk/pull/28564/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28564&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372755
  Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28564.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28564/head:pull/28564

PR: https://git.openjdk.org/jdk/pull/28564

From fbredberg at openjdk.org  Sat Nov 29 19:50:26 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Sat, 29 Nov 2025 19:50:26 GMT
Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file
Message-ID: <ipTJWgW8BT7Do6FRqG_ys3kekQe9B85pJQ9JI47-xjw=.6ad8f737-1dbf-4e61-a503-d1c77981f585@github.com>

The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893

By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean.

Passes tier1-7 without any problems that can be traced to this PR.

-------------

Commit messages:
 - Merge branch 'master' into 8371347_object_monitor_table_in_separate_file
 - 8371347: Move the ObjectMonitorTable to a separate new file

Changes: https://git.openjdk.org/jdk/pull/28565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371347
  Stats: 655 lines in 3 files changed: 370 ins; 285 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28565/head:pull/28565

PR: https://git.openjdk.org/jdk/pull/28565

From liach at openjdk.org  Sun Nov 30 05:24:43 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 05:24:43 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
Message-ID: <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>

> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
> 
> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
> 
> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
> 
> Paging @minborg who requested Optional folding for review.
> 
> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Essay

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28540/files
  - new: https://git.openjdk.org/jdk/pull/28540/files/f02b9da2..712dbf1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=00-01

  Stats: 150 lines in 2 files changed: 130 ins; 8 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540

PR: https://git.openjdk.org/jdk/pull/28540

From liach at openjdk.org  Sun Nov 30 05:24:44 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 05:24:44 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
 <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
Message-ID: <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>

On Sat, 29 Nov 2025 07:10:20 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.
>
> Hello Chen,
> 
>> because otherwise people can just blanket-approve java.util classes for trusting and break those applications.
> 
> This is one of the reasons why I asked some of the questions that I did. We have seen several PRs in the recent past where `@Stable` annotation has been introduced in the core classes of Java SE because it aids constant folding optimizations. Most of those changes have been backed merely by JMH benchmarks. It won't be a surprise if we start seeing another round of PRs where the usage of this new `@TrustFinalFields` gets proposed to some of these classes in the JDK because it shows an improvement in some micro benchmark. It also won't be a surprise if those PRs too won't have associated regression tests. Furthermore, unlike `@Stable` which gets applied directly on the field(s) of interest, this new annotation will be applied a bit "far away" from such fields. So it will need additional review cycles to understand if this usage can impact the code functionally in any manner. Specifying the semantics of this annotation in various usage scenarios, in its javadoc, will aid in reviewing 
 such changes in future, instead of having to regularly look into the JVM code to understand how this annotation behaves.
> 
> Classes in `java.util` aren't special in any way. So if applications are changing the values of final fields of some of those classes, then the same would be done for other packages of Java SE APIs too. If, like you note, applying `@TrustFinalFields` on such classes is going to break applications, then it will be useful to specify what kind of breakages those will be (in a similar manner to what the `@Stable` annotation's javadoc does).
> 
> Very specifically, I think adding a few sentences clarifying the following scenarios in this annotation's javadoc will be useful:
> 
> - Will this annotation be honoured only on the specific class that it is applied to? Or will it be taken into consideration for final fields in subclasses too? 
> - If this annotation gets applied on a class and if that class has some final fields which are already marked `@Stable`, what kind of implications will that have, if any?
> - If this annotation is marked on a class which has a `final` array field (for example `final long[] ids`), is it useful to continue placing a `@Stable` annotation on such array fields if the elements of those arrays are going to be initialized to a non-default value just once?
> - If after all the precautions are taken, if the final field of a class...

If you want an essay, I have written one - I just hope whatever bikeshedding for this essay does not affect the progress of Lazy Constant's performance demands.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573355600

From alanb at openjdk.org  Sun Nov 30 07:51:51 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Nov 2025 07:51:51 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
Message-ID: <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>

On Sun, 30 Nov 2025 05:24:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util.
>> 
>> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField.
>> 
>> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test.
>> 
>> Paging @minborg who requested Optional folding for review.
>> 
>> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Essay

src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 1:

> 1: Constant Folding in the Hotspot Compiler

I assume any write-up of HotSpot constant folding should move into src/hotspot tree, maybe a block comment in one of the source files?

src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 106:

> 104: `trustedFinal` setting.
> 105: 
> 106: ### Make Final Mean Final

I think you can drop this section for now. It's okay to reference JEP 500 but it will be annoying to have to maintain this text as there are many steps to follow this one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573492977
PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573493426

From alanb at openjdk.org  Sun Nov 30 07:54:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Nov 2025 07:54:46 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
 <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
 <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>
Message-ID: <h76V5hGnLdtKJxC8n93b0fqom8auRdttN9d8vU_UGFk=.9e67adba-ec7d-45b9-be65-cacf2c11dd32@github.com>

On Sun, 30 Nov 2025 05:19:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hello Chen,
>> 
>>> because otherwise people can just blanket-approve java.util classes for trusting and break those applications.
>> 
>> This is one of the reasons why I asked some of the questions that I did. We have seen several PRs in the recent past where `@Stable` annotation has been introduced in the core classes of Java SE because it aids constant folding optimizations. Most of those changes have been backed merely by JMH benchmarks. It won't be a surprise if we start seeing another round of PRs where the usage of this new `@TrustFinalFields` gets proposed to some of these classes in the JDK because it shows an improvement in some micro benchmark. It also won't be a surprise if those PRs too won't have associated regression tests. Furthermore, unlike `@Stable` which gets applied directly on the field(s) of interest, this new annotation will be applied a bit "far away" from such fields. So it will need additional review cycles to understand if this usage can impact the code functionally in any manner. Specifying the semantics of this annotation in various usage scenarios, in its javadoc, will aid in reviewing
  such changes in future, instead of having to regularly look into the JVM code to understand how this annotation behaves.
>> 
>> Classes in `java.util` aren't special in any way. So if applications are changing the values of final fields of some of those classes, then the same would be done for other packages of Java SE APIs too. If, like you note, applying `@TrustFinalFields` on such classes is going to break applications, then it will be useful to specify what kind of breakages those will be (in a similar manner to what the `@Stable` annotation's javadoc does).
>> 
>> Very specifically, I think adding a few sentences clarifying the following scenarios in this annotation's javadoc will be useful:
>> 
>> - Will this annotation be honoured only on the specific class that it is applied to? Or will it be taken into consideration for final fields in subclasses too? 
>> - If this annotation gets applied on a class and if that class has some final fields which are already marked `@Stable`, what kind of implications will that have, if any?
>> - If this annotation is marked on a class which has a `final` array field (for example `final long[] ids`), is it useful to continue placing a `@Stable` annotation on such array fields if the elements of those arrays are going to be initialized to a non-default value just once?
>> - If after all the precautions are taken, if...
>
> If you want an essay, I have written one - I just hope whatever bikeshedding for this essay does not affect the progress of Lazy Constant's performance demands.

> * If after all the precautions are taken, if the final field of a class annotated with `@TrustFinalFields` does get updated to a new value, what kind of impact would it have (stating that such behaviour is unspecified and in general is a bad idea would be enough, if that's all there is to it)

Field.set, which is probably the API that these libraries are using, already includes a warning about "unpredictable effects, including cases in which other parts of a program continue to use the original value of this field", so I think that is okay for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573494589

From alanb at openjdk.org  Sun Nov 30 08:07:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 30 Nov 2025 08:07:46 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <h76V5hGnLdtKJxC8n93b0fqom8auRdttN9d8vU_UGFk=.9e67adba-ec7d-45b9-be65-cacf2c11dd32@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <u7wvtiuE1ofUaGy3Nq413C8PqTOLIe5gaxCvK3-r36c=.04dd39d4-1eed-4a5f-a9f3-5a8159614ac9@github.com>
 <GxFTzCGqbbco91RCZPN54XQuOcB8SqMmvzv5ywraec4=.99cf1e69-2e25-4153-bdb2-d50abd2b6649@github.com>
 <M3hz_PEeeTq9hv1sILPH8Yo1gc4niM7exDbultklRJQ=.8c82e3ff-8ca8-4ba0-b550-43ee11170ad8@github.com>
 <TvUzakskfYFBfgX8a2mLmeLUrPnxauvl2Uf7GD5Klns=.ec0fdd74-3b7d-446a-a22a-53cb885358b3@github.com>
 <h76V5hGnLdtKJxC8n93b0fqom8auRdttN9d8vU_UGFk=.9e67adba-ec7d-45b9-be65-cacf2c11dd32@github.com>
Message-ID: <wTT9gIxnm6lIjpOCpkaPVjS1BN1zWN_w0F-Xo4f-bZQ=.32e466bb-7f44-4371-876a-6cf3e11153e8@github.com>

On Sun, 30 Nov 2025 07:51:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If you want an essay, I have written one - I just hope whatever bikeshedding for this essay does not affect the progress of Lazy Constant's performance demands.
>
>> * If after all the precautions are taken, if the final field of a class annotated with `@TrustFinalFields` does get updated to a new value, what kind of impact would it have (stating that such behaviour is unspecified and in general is a bad idea would be enough, if that's all there is to it)
> 
> Field.set, which is probably the API that these libraries are using, already includes a warning about "unpredictable effects, including cases in which other parts of a program continue to use the original value of this field", so I think that is okay for now.

> Existing users have been hacking java.util final fields. I think leaving out the backward compatibility part causes more trouble, because otherwise people can just blanket-approve java.util classes for trusting and break those applications.

I don't think we have a lot of data on this as it doesn't lend itself to static analysis. Aside from serialization libraries, it's possible the hacking of finals is ad hoc and in random areas (someone pointed to something in Netty hacking a final field in a class in sun.nio.ch at one point). So I probably wouldn't call out java.util specifically but maybe you brought that up specifically as there are so many performance critical classes there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573499552

From liach at openjdk.org  Sun Nov 30 14:52:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 14:52:53 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <w-LIyF7YVEs08VXf557Cn36LPFDkU2ma4dC1LdUOPe0=.ce2aa819-6718-48fc-90d2-39a086cb6649@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
 <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>
 <w-LIyF7YVEs08VXf557Cn36LPFDkU2ma4dC1LdUOPe0=.ce2aa819-6718-48fc-90d2-39a086cb6649@github.com>
Message-ID: <Xda9WTd21w9uuSF0q4iFLrUAuIn9Qd-oN2LJyNG1nds=.3a7a1133-83a4-4eba-a25b-3b69c219f0ca@github.com>

On Sun, 30 Nov 2025 14:50:23 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 1:
>> 
>>> 1: Constant Folding in the Hotspot Compiler
>> 
>> I assume any write-up of HotSpot constant folding should move into src/hotspot tree, maybe a block comment in one of the source files?
>
> I intend this to be a user-oriented guide on constant folding. I should just call it constant folding.

I intend this to be a user-oriented guide on constant folding. I should just call it constant folding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573814847

From liach at openjdk.org  Sun Nov 30 14:52:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 14:52:52 GMT
Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final
 field trusting [v2]
In-Reply-To: <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>
References: <QRWEkLVqMnYwQG6_-5wskQPviMQx4w_TFAZCnW1irpI=.05fdc011-e7af-4a92-b452-2309e1512699@github.com>
 <HlQa5OEUKZR5EzxgVk9MP8PqsLVcSdIHi5Ruf4M4iKU=.a5b9fd4d-d631-4e99-8dd8-c9cc9f28aea4@github.com>
 <RioTxs6EP8H6oW3DRnJsZm12OP1WNjKxumyERgD_MjA=.72b3557b-c85e-42a1-beb4-b2efb065c5e8@github.com>
Message-ID: <w-LIyF7YVEs08VXf557Cn36LPFDkU2ma4dC1LdUOPe0=.ce2aa819-6718-48fc-90d2-39a086cb6649@github.com>

On Sun, 30 Nov 2025 07:47:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Essay
>
> src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 1:
> 
>> 1: Constant Folding in the Hotspot Compiler
> 
> I assume any write-up of HotSpot constant folding should move into src/hotspot tree, maybe a block comment in one of the source files?

I intend this to be a user-oriented guide on constant folding. I should just call it constant folding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2573814710

From dholmes at openjdk.org  Sun Nov 30 21:40:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 30 Nov 2025 21:40:47 GMT
Subject: RFR: 8371347: Move the ObjectMonitorTable to a separate new file
In-Reply-To: <ipTJWgW8BT7Do6FRqG_ys3kekQe9B85pJQ9JI47-xjw=.6ad8f737-1dbf-4e61-a503-d1c77981f585@github.com>
References: <ipTJWgW8BT7Do6FRqG_ys3kekQe9B85pJQ9JI47-xjw=.6ad8f737-1dbf-4e61-a503-d1c77981f585@github.com>
Message-ID: <HlmvXQ2OzlxaoOneFF36-FeBciUDssTmgh0gGtquhSU=.6507b72b-9419-404e-af55-91de37df0931@github.com>

On Sat, 29 Nov 2025 11:21:52 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> The request to move the `ObjectMonitorTable` to a separate new file came from this review comment: https://github.com/openjdk/jdk/pull/27915#discussion_r2459848893
> 
> By moving the `ObjectMonitorTable` implementation out of `runtime/synchronizer.cpp` into `runtime/objectMonitorTable.[ch]pp` will make a future transition from the current `ObjectMonitorTable` implementation to a new (and better) implementation appear more clean.
> 
> Passes tier1-7 without any problems that can be traced to this PR.

Seems fine. I did not verify line by line :) 

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28565#pullrequestreview-3522427892