From stuefe at openjdk.org  Sat Mar  1 06:04:08 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 1 Mar 2025 06:04:08 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v4]
In-Reply-To: <AfMTXz_qIv9YtPNcDE8LPIIu0ulaa-bXLsXnkP6LAi4=.c1ed59e0-29d8-410a-a78e-6997b24d9fa2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <o1OMjjScMoYA57Rjj8VsjYM5suvI3yjCcrFA__3LGhE=.36dd17ab-dad5-4291-a024-2d196add622f@github.com>
 <LlQrGeDWZQmtE39W4XxUbTTUX8GRWk4yQ4g57M5aL8Y=.5a7f0273-88b4-4288-9ced-67e5dce8e287@github.com>
 <ICOrVtN9o06dHWoN92q2Pi5aEsUdPYgZhMiBBYL9onk=.3d6d843b-f173-4512-b98a-6f54c0bb0c95@github.com>
 <AfMTXz_qIv9YtPNcDE8LPIIu0ulaa-bXLsXnkP6LAi4=.c1ed59e0-29d8-410a-a78e-6997b24d9fa2@github.com>
Message-ID: <VHx8Z0Osk3lRtwC4SvRAQAUDv-lJwWK_iqUN5IbLWa4=.0fd45954-d07f-4c2e-9942-004b1a3003f5@github.com>

On Wed, 26 Feb 2025 04:17:54 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> We are only interested in a rise that rose significantly above **both** the start and end point of the measurements. 
>> 
>> E.g.:
>> - if we have this: start = 0, end = 20MB, peak = 20MB, this is not a temporary peak and we already know that the end usage is 20MB.
>> - if we have this: start = 20MB, end = 0, peak = 20MB, this is not a temporary peak either, because we already know the starting footprint was 20MB.
>> - but if we have start = 0, end = 0, peak = 20MB, this is interesting since if we just print start and end we will miss the fact that in between those times we had temporarily allocated 20MB.
>
> Thanks for the explanation. It would be great if some comment can be added, possibly along with some example like the one in the previous comment, to explain the meaning of `temporary_peak_size` and the corresponding calculation.

Will do. Thank you, @ashu-mehra !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1976316773

From stuefe at openjdk.org  Sat Mar  1 06:12:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 1 Mar 2025 06:12:55 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <aDVfrInJddv5fFYbNkGQc__nSsw0jiQZk4fbkEC4BmM=.aa5caef9-756c-43e5-aa86-3330185d2f00@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
 <aDVfrInJddv5fFYbNkGQc__nSsw0jiQZk4fbkEC4BmM=.aa5caef9-756c-43e5-aa86-3330185d2f00@github.com>
Message-ID: <hp7CfPi5AfanH81niGDWRKLJ6nDGZuAdKexK-_P8lCQ=.dbf3d531-e633-4bd8-9c1a-81864eea9bb2@github.com>

On Wed, 26 Feb 2025 12:33:14 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - feedback ashu
>>  - feedback roberto
>>  - final-statistics-switch
>>  - performance fix
>>  - remove test code
>
> src/hotspot/share/compiler/compilationMemoryStatistic.cpp line 306:
> 
>> 304:   if (_comp_type == compiler_c2) {
>> 305:     // Update C2 node count
>> 306:     // Careful, Compile::current() may be NULL in a short time window when Compile itself
> 
> The recently added `sources/TestNoNULL.java` test fails due to this occurrence of `NULL`.
> Suggestion:
> 
>     // Careful, Compile::current() may be null in a short time window when Compile itself

Thanks. We should add those to GHAs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1976320472

From stuefe at openjdk.org  Sun Mar  2 06:47:04 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 2 Mar 2025 06:47:04 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <q8f16tTi4UhRGTjPDrYDBpqKfiSxqDvPyxT5XdLN_qg=.373a7164-f2f3-48d5-874a-765e1ea6fba3@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
 <q8f16tTi4UhRGTjPDrYDBpqKfiSxqDvPyxT5XdLN_qg=.373a7164-f2f3-48d5-874a-765e1ea6fba3@github.com>
Message-ID: <9BZo8JdBff5sPxUOb-TTgKsfkFAetyNF4lOi-h7Xnus=.cc03855c-8ea6-4ad9-89e0-f82a7996471f@github.com>

On Thu, 27 Feb 2025 10:04:04 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - feedback ashu
>>  - feedback roberto
>>  - final-statistics-switch
>>  - performance fix
>>  - remove test code
>
> src/hotspot/share/compiler/compilationMemStatInternals.hpp line 243:
> 
>> 241:   int retrieve_live_node_count() const;
>> 242: 
>> 243:   DEBUG_ONLY(void verify() const;)
> 
> Unused. I suggest to either call this function from some appropriate point (in debug mode only) or just remove it.

I'll use it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1976553526

From stuefe at openjdk.org  Sun Mar  2 06:56:05 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 2 Mar 2025 06:56:05 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <q8f16tTi4UhRGTjPDrYDBpqKfiSxqDvPyxT5XdLN_qg=.373a7164-f2f3-48d5-874a-765e1ea6fba3@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
 <q8f16tTi4UhRGTjPDrYDBpqKfiSxqDvPyxT5XdLN_qg=.373a7164-f2f3-48d5-874a-765e1ea6fba3@github.com>
Message-ID: <gNx2mC1KKZv6bJ0wrUoApSV2OL2C9R_2zbUOyXw-pPM=.e353ae7c-0247-4007-a1c6-0d92574b8088@github.com>

On Thu, 27 Feb 2025 10:08:50 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - feedback ashu
>>  - feedback roberto
>>  - final-statistics-switch
>>  - performance fix
>>  - remove test code
>
> src/hotspot/share/utilities/ostream.cpp line 225:
> 
>> 223:   while (count > 0) {
>> 224:     int nw = (count > 8) ? 8 : count;
>> 225:     this->write(tmp, nw);
> 
> Are these changes essential for the rest of the changeset? If not, I would suggest to leave them to a separate RFE, for simplicity.

Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1976554529

From stuefe at openjdk.org  Sun Mar  2 07:04:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 2 Mar 2025 07:04:55 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v6]
In-Reply-To: <q8f16tTi4UhRGTjPDrYDBpqKfiSxqDvPyxT5XdLN_qg=.373a7164-f2f3-48d5-874a-765e1ea6fba3@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <gHpc-UgkVvOlYPdqXF7XMgXytY7g7wA6QdTTPMxk3l0=.ef8d3f43-44e4-4be8-8caf-b7808ca3febf@github.com>
 <q8f16tTi4UhRGTjPDrYDBpqKfiSxqDvPyxT5XdLN_qg=.373a7164-f2f3-48d5-874a-765e1ea6fba3@github.com>
Message-ID: <3nlpgZQdqbh5M1_v_qFHpm_qzDm0anEGiGTJInDIEyw=.e13d4287-5822-4087-81d2-837a9ea8a5cc@github.com>

On Thu, 27 Feb 2025 10:11:37 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - feedback ashu
>>  - feedback roberto
>>  - final-statistics-switch
>>  - performance fix
>>  - remove test code
>
> src/hotspot/share/runtime/globals.hpp line 1402:
> 
>> 1400:           "Print metaspace statistics upon VM exit.")                       \
>> 1401:                                                                             \
>> 1402:   product(bool, PrintCompilerMemoryStatisticsAtExit, false, DIAGNOSTIC,     \
> 
> Would it be possible to add a test for this new flag, perhaps by extending the existing test logic in `CompileCommandPrintMemStat`?

The test is already there - we test the final print output in CompileCommandPrintMemStat.java. I will change the logic however and only print the final output if `PrintCompilerMemoryStatisticsAtExit` is given (before, it was also printed, and tested as part of, CompilerCommand memstat). Then I will explicitly pass this flag in the test. That should be good enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1976555741

From stuefe at openjdk.org  Sun Mar  2 07:20:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 2 Mar 2025 07:20:58 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v7]
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <6SXwVSMnVb6f5MJ433OJnuircxxdfhyVOaYLtAblxNM=.6a629eb0-4949-499b-bb65-56b1ca514cba@github.com>

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision:

 - Feedback Roberto cont.
 - Roberto Arenas
 - NULL in comment
 - feedback ashu

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/3052ddf8..d1dbba60

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

  Stats: 56 lines in 16 files changed: 9 ins; 32 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23530/head:pull/23530

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

From stuefe at openjdk.org  Sun Mar  2 07:20:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 2 Mar 2025 07:20:58 GMT
Subject: RFR: 8344009: Improve compiler memory statistics
In-Reply-To: <P0R02Qxn6MxYrUWAP-sHxzIQUOXXMLmrOFbpPmkmWDQ=.2486a05d-a9f9-44b2-ab7e-0d60e15fcf3b@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <NOSIT_kdGcid-dyl6nc39bIkC6r77AiYO9cro9JSAzg=.58ad12d8-d148-49a5-a913-728a125efd57@github.com>
 <BZ75vWNe1HwDNyvicPptSgQii-D8ckHyzTXH6Hu3ZnQ=.3d326f78-be25-41dd-8018-d0540bfcf793@github.com>
 <IVG_vcOUOaACqheVRCqkdUQfphlM6nK7xRlzmE6LvE0=.9a96d747-18f0-476c-94fe-b6cd8621ee95@github.com>
 <iwaAAcKMdzFWCjmAELKt1NdYO27dkFoZOU8alU3M6sU=.a8fe263b-c589-4d85-a272-1708530ff6cf@github.com>
 <0wHGNSlwe7cWb7Plad2n8Swy8rayYTAf5IETuw9zl4U=.a4d6a129-aebc-4639-aaef-92ee6c4552c7@github.com>
 <NfX5WX4NU_kD7dQcZjpaN3z28TDcsg2OIJjXjpZv_-s=.34848957-da62-430c-ae40-a57f32f10cfb@github.com>
 <P0R02Qxn6MxYrUWAP-sHxzIQUOXXMLmrOFbpPmkmWDQ=.2486a05d-a9f9-44b2-ab7e-0d60e15fcf3b@github.com>
Message-ID: <ZKgbQ0hMWaxDyEODNNoIXH7sVb9OrneWzqmID7YWjro=.dcf791ab-619e-49bc-9bd2-ff004dfca52e@github.com>

On Wed, 26 Feb 2025 13:00:51 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>>> > @robcasloz I identified and hopefully fixed a small issue that hit the "disabled" path. Turns out we allocate arena chunks a lot more frequently than I thought, and the new unconditional call to Thread::current() in there was hurting a bit. I now avoid this unless I know the statistic is enabled.
>>> > With this patch, on my machine the difference between unpatched and patched JVM with stats disabled is below one standard deviation for the benchmark in question.
>>> 
>>> Great, thanks! Will re-run benchmarking and report results early next week.
>> 
>> Functional test results (Oracle tier1-5) still look good for the latest commit (dd7a06ad). I can confirm that the C2 speed regression on our linux-x64 machines is almost fully mitigated. The 2-3% regression on our macosx-aarch64 machines does not seem to be addressed by the latest changes though, but as I mentioned before I think it is in the acceptable range (and only affects one benchmark).
>
>> @robcasloz, @ashu-mehra thanks a lot for your reviews. I incorporated most of them into the PR.
> 
> Thanks, Thomas! I see that the changes suggested in https://github.com/openjdk/jdk/commit/d501bd8a674229904358fb168a9c347004efeea3 are not incorporated, is it because you find them out of the scope of this PR? I would argue that at least tagging `Compile::_Compile_types` with `tag_type` is relevant and in line with the other changes included in this PR, e.g. [this one](https://github.com/openjdk/jdk/pull/23530/files#diff-3559dcf23b719805be5fd06fd5c1851dbd8f53e47afe6d99cba13a3de0ebc6b2R443).

@robcasloz I think I addressed all of your concerns. Thanks for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2692596999

From sgehwolf at openjdk.org  Sun Mar  2 19:10:06 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Sun, 2 Mar 2025 19:10:06 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
Message-ID: <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>

On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright headers

OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2652794986

From dholmes at openjdk.org  Sun Mar  2 20:56:55 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 2 Mar 2025 20:56:55 GMT
Subject: RFR: 8350818: Improve OperatingSystemMXBean cpu load tests to not
 accept -1.0 by default
In-Reply-To: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
References: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
Message-ID: <OeuwF4Wil3172tkQNjVJSgkLebYp2zKr-Yr0Ka84PU8=.25521798-6226-4c16-adf3-6d7cdff74f27@github.com>

On Fri, 28 Feb 2025 00:05:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820
> 
> The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
> If this functionality doesn't work on certain configurations then they should be excluded.
> 
> The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
> I filed separate PR to backport fix easier.
> Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
> Might be it would be better. just to rename the whole test later.

@lmesnik this test is now failing a lot in our CI! I will file a new bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/23833#issuecomment-2692902822

From dholmes at openjdk.org  Sun Mar  2 21:02:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 2 Mar 2025 21:02:01 GMT
Subject: RFR: 8350818: Improve OperatingSystemMXBean cpu load tests to not
 accept -1.0 by default
In-Reply-To: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
References: <QXfJ9-t68HurGLxlrnbrNGALIn6h_JnTvRV79qrLXLk=.74d8d939-b422-46ce-8200-3e5f1218a11f@github.com>
Message-ID: <SX8mC2FEqOGgoqFzsVWE8uUUlwLiny61mvDmPgafiIc=.4d0a020a-dc70-49a9-b33e-b1a6c52be301@github.com>

On Fri, 28 Feb 2025 00:05:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The cpuLoad tests were updated to fail if -1.0 returns to catch bugs like https://bugs.openjdk.org/browse/JDK-8350820
> 
> The -1.0 means that JDK can't obtain cpu load. It shouldn't be returned.
> If this functionality doesn't work on certain configurations then they should be excluded.
> 
> The fix should be pushed after https://bugs.openjdk.org/browse/JDK-8350820
> I filed separate PR to backport fix easier.
> Also, I haven't changed indentation and didn't change getSystemCpuLoad to getCpuLoad. They return same. 
> Might be it would be better. just to rename the whole test later.

I see [JDK-8351002](https://bugs.openjdk.org/browse/JDK-8351002) was already filed

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

PR Comment: https://git.openjdk.org/jdk/pull/23833#issuecomment-2692905065

From schernyshev at openjdk.org  Sun Mar  2 21:19:58 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Sun, 2 Mar 2025 21:19:58 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
Message-ID: <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>

On Sun, 2 Mar 2025 19:07:32 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.

Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2692912180

From dholmes at openjdk.org  Mon Mar  3 04:55:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 3 Mar 2025 04:55:51 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <wejMqtmaVkvy-z3h7pFXCDh4bVemMjGXoA_BWACQIkg=.59e7b61e-1a69-4370-8033-f7b172852b26@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

I agree that the call to `JNI_GetCreatedJavaVMs` serves no purpose.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2653050130

From sgehwolf at openjdk.org  Mon Mar  3 07:52:59 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 3 Mar 2025 07:52:59 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
 <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
Message-ID: <G_wIU-Le8V4pijadumNrxaJbLz2S33YuAyiza5iobm4=.17171ebe-f85e-4795-af6f-445437c86c87@github.com>

On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> > OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
> 
> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.

OK!

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2693536580

From alanb at openjdk.org  Mon Mar  3 08:06:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Mar 2025 08:06:52 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <vcjJkRZ_3tEWWrUMlsW8MDnoS1jSYifSGMRFQjZql_Q=.bd0934b1-7ee7-43df-829a-00007e6a34d7@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

It was needed when the test was originally created but it has changed significantly, and the addition of Agent_OnAttach in one of the updates meant the JavaVM* is provided, no need to call JNI_GetCreatedJavaVMs anymore.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23835#pullrequestreview-2653333029

From rcastanedalo at openjdk.org  Mon Mar  3 09:19:55 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 3 Mar 2025 09:19:55 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v7]
In-Reply-To: <6SXwVSMnVb6f5MJ433OJnuircxxdfhyVOaYLtAblxNM=.6a629eb0-4949-499b-bb65-56b1ca514cba@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <6SXwVSMnVb6f5MJ433OJnuircxxdfhyVOaYLtAblxNM=.6a629eb0-4949-499b-bb65-56b1ca514cba@github.com>
Message-ID: <QAH1tDOu-_LCb99UgKvxJVdHYLWb7vyWqhXKLtG6U2k=.33bd50ce-e514-4037-b80e-1623fbc3e057@github.com>

On Sun, 2 Mar 2025 07:20:58 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Feedback Roberto cont.
>  - Roberto Arenas
>  - NULL in comment
>  - feedback ashu

Thanks for addressing my comments! The latest changeset looks good (modulo unnecessary changes in `ostream.hpp`) and passes all tier1-5 tests in Oracle's test pipeline.

src/hotspot/share/utilities/ostream.hpp line 1:

> 1: /*

Please revert the unnecessary changes in this file as well.

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

Marked as reviewed by rcastanedalo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23530#pullrequestreview-2653497625
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1977135658

From dfuchs at openjdk.org  Mon Mar  3 09:59:56 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Mar 2025 09:59:56 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v3]
In-Reply-To: <8RA6woqoHj8ww-8iByQhCARsURNi5fWbLd7qR2by07E=.aef766be-2dad-4959-9451-6bcc8f508c8e@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <8RA6woqoHj8ww-8iByQhCARsURNi5fWbLd7qR2by07E=.aef766be-2dad-4959-9451-6bcc8f508c8e@github.com>
Message-ID: <-BWuY6rUaiaLe77LDTNH8DbHNv0n3TKok4cenj_7ZYU=.dc1595c3-9843-48bc-85cc-8cbc1841c12f@github.com>

On Mon, 24 Feb 2025 09:59:15 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
>> 
>> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.
>
> Kevin Walls 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:
> 
>  - constructor->method in deprecated tag
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - comments
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - (c)
>  - typo
>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>  - Also XMLParseException
>  - RMMB comment update
>  - Deprecate XML interchange in DescriptorSupport

src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 978:

> 976:      * thrown.
> 977:      * @deprecated This method exists for historical reasons.  If
> 978:      * reading from XML is required, it should be implemented externally.

Technically here it should be `writing to XML` - I don't think changing that would require re-submitting the CSR - but maybe @jddarcy could confirm?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1977207451

From stuefe at openjdk.org  Mon Mar  3 10:41:16 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 3 Mar 2025 10:41:16 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v8]
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <bTXw4wWJdRlhYLtR9f8btcTRv6s3wfWU9wXR8BhGeoI=.b48ce849-4433-4bf3-93f6-24bba831bb82@github.com>

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

Thomas Stuefe 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 20 additional commits since the last revision:

 - Merge branch 'master' into JDK-8344009-Improve-Compiler-memstat
 - remove unnecessary changes in osream.hpp
 - Feedback Roberto cont.
 - Roberto Arenas
 - NULL in comment
 - feedback ashu
 - feedback ashu
 - feedback roberto
 - final-statistics-switch
 - performance fix
 - ... and 10 more: https://git.openjdk.org/jdk/compare/7d4fd3ef...f82d37cd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23530/files
  - new: https://git.openjdk.org/jdk/pull/23530/files/d1dbba60..f82d37cd

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

  Stats: 20868 lines in 719 files changed: 10434 ins; 7437 del; 2997 mod
  Patch: https://git.openjdk.org/jdk/pull/23530.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23530/head:pull/23530

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

From stuefe at openjdk.org  Mon Mar  3 10:41:16 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 3 Mar 2025 10:41:16 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v7]
In-Reply-To: <QAH1tDOu-_LCb99UgKvxJVdHYLWb7vyWqhXKLtG6U2k=.33bd50ce-e514-4037-b80e-1623fbc3e057@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <6SXwVSMnVb6f5MJ433OJnuircxxdfhyVOaYLtAblxNM=.6a629eb0-4949-499b-bb65-56b1ca514cba@github.com>
 <QAH1tDOu-_LCb99UgKvxJVdHYLWb7vyWqhXKLtG6U2k=.33bd50ce-e514-4037-b80e-1623fbc3e057@github.com>
Message-ID: <FvsEUp5GoScLkW0ZyHi1Akpsrsai0RrBNaxB6YrkJL0=.f0356a06-9165-4211-885f-2965a943ba16@github.com>

On Mon, 3 Mar 2025 09:17:03 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Thanks for addressing my comments! The latest changeset looks good (modulo unnecessary changes in `ostream.hpp`) and passes all tier1-5 tests in Oracle's test pipeline.

Many thanks, @robcasloz ! I also merged master and will wait for the last GHAs to finish. I may need a review update for the latest version.

> src/hotspot/share/utilities/ostream.hpp line 1:
> 
>> 1: /*
> 
> Please revert the unnecessary changes in this file as well.

Arrgh forgot those

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

PR Comment: https://git.openjdk.org/jdk/pull/23530#issuecomment-2693941082
PR Review Comment: https://git.openjdk.org/jdk/pull/23530#discussion_r1977277368

From yzheng at openjdk.org  Mon Mar  3 12:10:59 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 3 Mar 2025 12:10:59 GMT
Subject: RFR: 8315488: Remove outdated and unused ciReplay support from SA
 [v7]
In-Reply-To: <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
Message-ID: <rd-cWg8bYxYj62iwUyS-b228ihizom-D7HPsjZmiZDc=.30a96627-7214-4197-9458-fc823510b266@github.com>

On Fri, 28 Feb 2025 18:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix COMPILER2 preprocessor constant for SA.

JVMCI changes LGTM

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

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/23782#pullrequestreview-2653911941

From coleenp at openjdk.org  Mon Mar  3 12:11:00 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 12:11:00 GMT
Subject: RFR: 8315488: Remove outdated and unused ciReplay support from SA
 [v7]
In-Reply-To: <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
 <hjMWnfOErQ_IWQvfLp1qoSiSr8P-KtnY57HWYTWW-ro=.977534bc-c76b-4b4c-a5a6-8183c613714b@github.com>
Message-ID: <CIqyDvdblLbXABCNIZ24p7QSbTfioMc_K0b0P9VUmH0=.1d2ccb3a-a439-4d1d-b523-39ad87c0df6a@github.com>

On Fri, 28 Feb 2025 18:10:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix COMPILER2 preprocessor constant for SA.

Thank you for reviewing Chris, Vladimir and Yudi.

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

PR Comment: https://git.openjdk.org/jdk/pull/23782#issuecomment-2694143147

From coleenp at openjdk.org  Mon Mar  3 12:11:03 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 3 Mar 2025 12:11:03 GMT
Subject: Integrated: 8315488: Remove outdated and unused ciReplay support from
 SA
In-Reply-To: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
References: <MXpmC5nD_PeV6yEhHHYkTKRjkjteKb5XwiV_4-58vpE=.45268e49-c6ef-4656-bd63-4102a1b5cc43@github.com>
Message-ID: <-j80eG15F0UcrdIeoOpXnPIxNWXoYp-7mngi5jeI7SE=.c36e2006-972f-4206-86ca-bcd0b3d92466@github.com>

On Tue, 25 Feb 2025 16:52:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the ci, c1 and c2 compiler code from the serviceability agent.  The ciReplay functionality is supported inside the jvm and this duplicated functionality in SA had bit rotted so is removed.
> Tested with tier1-4.

This pull request has now been integrated.

Changeset: 8b0468fa
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8b0468faf1c38f2d1d887ab92b76dfff625482ef
Stats:     6022 lines in 109 files changed: 2 ins; 5837 del; 183 mod

8315488: Remove outdated and unused ciReplay support from SA

Reviewed-by: kvn, cjplummer, yzheng

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

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

From kevinw at openjdk.org  Mon Mar  3 12:27:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 3 Mar 2025 12:27:28 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v4]
In-Reply-To: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
Message-ID: <APDeeRg3L0rnPQzU1oWQ6YNV5a-4_SljX8KFvrTzo-E=.810a5ec2-1168-48de-af91-7825d1cc7c6f@github.com>

> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
> 
> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  reading to writing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23038/files
  - new: https://git.openjdk.org/jdk/pull/23038/files/04d627c7..acdfef2b

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

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

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

From kevinw at openjdk.org  Mon Mar  3 12:41:00 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 3 Mar 2025 12:41:00 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v3]
In-Reply-To: <-BWuY6rUaiaLe77LDTNH8DbHNv0n3TKok4cenj_7ZYU=.dc1595c3-9843-48bc-85cc-8cbc1841c12f@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <8RA6woqoHj8ww-8iByQhCARsURNi5fWbLd7qR2by07E=.aef766be-2dad-4959-9451-6bcc8f508c8e@github.com>
 <-BWuY6rUaiaLe77LDTNH8DbHNv0n3TKok4cenj_7ZYU=.dc1595c3-9843-48bc-85cc-8cbc1841c12f@github.com>
Message-ID: <1HijXo7xzpOTPjHGXRRjMiR639jfRFkrMS98w7t4qXU=.49b6f46d-7416-44e8-9942-d2564611d07f@github.com>

On Mon, 3 Mar 2025 09:56:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Kevin Walls 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:
>> 
>>  - constructor->method in deprecated tag
>>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>>  - comments
>>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>>  - (c)
>>  - typo
>>  - Merge remote-tracking branch 'upstream/master' into 8347433_DescriptorSupport_deprecate_XML
>>  - Also XMLParseException
>>  - RMMB comment update
>>  - Deprecate XML interchange in DescriptorSupport
>
> src/java.management/share/classes/javax/management/modelmbean/DescriptorSupport.java line 978:
> 
>> 976:      * thrown.
>> 977:      * @deprecated This method exists for historical reasons.  If
>> 978:      * reading from XML is required, it should be implemented externally.
> 
> Technically here it should be `writing to XML` - I don't think changing that would require re-submitting the CSR - but maybe @jddarcy could confirm?

Thanks, done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23038#discussion_r1977450609

From kevinw at openjdk.org  Mon Mar  3 12:48:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 3 Mar 2025 12:48:59 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v4]
In-Reply-To: <APDeeRg3L0rnPQzU1oWQ6YNV5a-4_SljX8KFvrTzo-E=.810a5ec2-1168-48de-af91-7825d1cc7c6f@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <APDeeRg3L0rnPQzU1oWQ6YNV5a-4_SljX8KFvrTzo-E=.810a5ec2-1168-48de-af91-7825d1cc7c6f@github.com>
Message-ID: <mQt5KDJOaj7lzB_NxmRvXE4OMJJ0GE4AQKr6p41Hs0s=.d700d7e0-aac1-436d-945b-d66c6de30939@github.com>

On Mon, 3 Mar 2025 12:27:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
>> 
>> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reading to writing

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23038#issuecomment-2694283759

From dfuchs at openjdk.org  Mon Mar  3 12:48:58 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 3 Mar 2025 12:48:58 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v4]
In-Reply-To: <APDeeRg3L0rnPQzU1oWQ6YNV5a-4_SljX8KFvrTzo-E=.810a5ec2-1168-48de-af91-7825d1cc7c6f@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <APDeeRg3L0rnPQzU1oWQ6YNV5a-4_SljX8KFvrTzo-E=.810a5ec2-1168-48de-af91-7825d1cc7c6f@github.com>
Message-ID: <8BuyUXgg_yGcLE7Mtt4nO4ldUFplMeqWuYY0vqKBcQo=.bcc28157-5905-4121-b47b-76aa3d1ee050@github.com>

On Mon, 3 Mar 2025 12:27:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
>> 
>> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reading to writing

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23038#pullrequestreview-2654035531

From rcastanedalo at openjdk.org  Mon Mar  3 14:19:03 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 3 Mar 2025 14:19:03 GMT
Subject: RFR: 8344009: Improve compiler memory statistics [v8]
In-Reply-To: <bTXw4wWJdRlhYLtR9f8btcTRv6s3wfWU9wXR8BhGeoI=.b48ce849-4433-4bf3-93f6-24bba831bb82@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
 <bTXw4wWJdRlhYLtR9f8btcTRv6s3wfWU9wXR8BhGeoI=.b48ce849-4433-4bf3-93f6-24bba831bb82@github.com>
Message-ID: <58iKQTQUKK7ChuZj6Pzq07VNuE1CFQKxHznKXJYFbM8=.3ce9fed9-62fd-48c4-bfac-75d41ffd06e8@github.com>

On Mon, 3 Mar 2025 10:41:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Greetings,
>> 
>> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
>> 
>> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
>> 
>> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
>> 
>> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
>> 
>> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
>> 
>> The statistic gives us two new forms of output:
>> 
>> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
>> 
>> 
>> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>>     incrementalInline           3992816         0   3043704    62...
>
> Thomas Stuefe 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 20 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8344009-Improve-Compiler-memstat
>  - remove unnecessary changes in osream.hpp
>  - Feedback Roberto cont.
>  - Roberto Arenas
>  - NULL in comment
>  - feedback ashu
>  - feedback ashu
>  - feedback roberto
>  - final-statistics-switch
>  - performance fix
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/06fe586a...f82d37cd

Marked as reviewed by rcastanedalo (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23530#pullrequestreview-2654253184

From stuefe at openjdk.org  Mon Mar  3 14:42:04 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 3 Mar 2025 14:42:04 GMT
Subject: Integrated: 8344009: Improve compiler memory statistics
In-Reply-To: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
References: <JMHDq_MrAe22zlNkWmYV6kslve7wZ1Si1tNtNl_u8jg=.74a5a263-3a19-4077-be8a-a267a55762c2@github.com>
Message-ID: <KnIhymGwUbJxA6qwbreYvp7ijNTYdja8KLWG3TLFD80=.2539cb34-5cda-4482-99a1-09d7b279e32e@github.com>

On Sat, 8 Feb 2025 06:56:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Greetings,
> 
> This is a rewrite of the Compiler Memory Statistic. The primary new feature is the capability to track allocations by C2 phases. This will allow for a much faster, more thorough analysis of footprint issues. 
> 
> Tracking Arena memory movement is not trivial since one needs to follow the ebb and flow of allocations over nested C2 phases. A phase typically allocates more than it releases, accruing new nodes and resource area. A phase can also release more than allocated when Arenas carried over from other phases go out of scope in this phase. Finally, it can have high temporary peaks that vanish before the phase ends.
> 
> I wanted to track that information correctly and display it clearly in a way that is easy to understand.
> 
> The patch implements per-phase tracking by instrumenting the `TracePhase` stack object (thanks to @rwestrel for this idea).
> 
> The nice thing with this technique is that it also allows for quick analysis of a suspected hot spot (eg, the inside of a loop): drop a TracePhase in there with a speaking name, and you can see the allocations inside that phase.
> 
> The statistic gives us two new forms of output:
> 
> 1) At the moment the compilation memory *peaked*, we now get a detailed breakdown of that peak usage per phase:
> 
> 
> Arena Usage by Arena Type and compilation phase, at arena usage peak of 58817816:
>     Phase                         Total        ra      node      comp      type     index   reglive  regsplit     cienv     other
>     none                        1205512    155104    982984     33712         0         0         0         0         0     33712
>     parse                      11685376    720016   6578728   1899064         0         0         0         0   1832888    654680
>     optimizer                    916584         0    556416         0         0         0         0         0         0    360168
>     escapeAnalysis              1983400         0   1276392    707008         0         0         0         0         0         0
>     connectionGraph              720016         0         0    621832         0         0         0         0     98184         0
>     macroEliminate               196448         0    196448         0         0         0         0         0         0         0
>     iterGVN                      327440         0    196368    131072         0         0         0         0         0         0
>     incrementalInline           3992816         0   3043704    621832         0         0         0         0    261824...

This pull request has now been integrated.

Changeset: db69ec9e
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db69ec9e583791d359c5c0acb504c7f01e963e3b
Stats:     1732 lines in 32 files changed: 1147 ins; 248 del; 337 mod

8344009: Improve compiler memory statistics

Reviewed-by: rcastanedalo, asmehra

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

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

From kevinw at openjdk.org  Mon Mar  3 17:17:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 3 Mar 2025 17:17:30 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
Message-ID: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>

Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).

This change moves to snprintf again, but the counter names are not truncated.

snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

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

Commit messages:
 - 8350939: Revisit Windows PDH buffer size calculation for OperatingSystemMXBean

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

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

From kevinw at openjdk.org  Mon Mar  3 17:17:30 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 3 Mar 2025 17:17:30 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

In makeFullCounterPath():

We calculate a size (length of the counter in characters), which might be '\Process(java#0)% Processor Time', 33 chars.
That size does not include the null terminator.
We malloc a buffer of (size+1).
Then we use the original size in the _snprintf.

This has worked for years.  But snprintf is slightly different.

snprintf behaviour:

https://en.cppreference.com/w/c/io/fprintf (including snprintf)
"At most bufsz - 1 characters are written. The resulting character string will be terminated with a null character"

That seems enough to say we have a problem.  Although its wording could be clearer on whether "bufsz-1 characters" includes the null.
	 
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170

"snprintf always stores a terminating NULL character, truncating the output if necessary."

"The difference is that if you run out of buffer, snprintf null-terminates the end of the buffer and returns the number of characters that would have been required whereas _snprintf doesn't null-terminate the buffer and returns -1. Also, snprintf() includes one more character in the output because it doesn't null-terminate the buffer."

(the last sentence quoted there seems to contradict the first)

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

Did we run out of buffer? 
snprintf called with a 33 char string and a buf len of 33, it won't have room for the null (there is room in the malloc'd buffer, but the len passed to snprintf does not include it).  So it truncates and writes a null within the bounds it knows about.

snprintf needs the null to fit inside the buffer length given.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2695039462

From jiangli at openjdk.org  Mon Mar  3 17:38:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 3 Mar 2025 17:38:56 GMT
Subject: Integrated: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <L9GbcUmMVIvHx8Nrb2yCNe-0hD4mEvdT0TUSS0N86-k=.1ea12469-b6a8-41d3-8b0c-21111fc3404e@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

This pull request has now been integrated.

Changeset: bb70896e
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bb70896e356536477cfb770096fb769485edc55b
Stats:     10 lines in 2 files changed: 0 ins; 9 del; 1 mod

8350903: Remove explicit libjvm.so dependency for libVThreadEventTest

Reviewed-by: dholmes, alanb

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

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

From jiangli at openjdk.org  Mon Mar  3 17:38:55 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 3 Mar 2025 17:38:55 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

Thanks for the reviews and historical info!

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2695103531

From sspitsyn at openjdk.org  Mon Mar  3 22:09:54 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 3 Mar 2025 22:09:54 GMT
Subject: RFR: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal [v4]
In-Reply-To: <APDeeRg3L0rnPQzU1oWQ6YNV5a-4_SljX8KFvrTzo-E=.810a5ec2-1168-48de-af91-7825d1cc7c6f@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
 <APDeeRg3L0rnPQzU1oWQ6YNV5a-4_SljX8KFvrTzo-E=.810a5ec2-1168-48de-af91-7825d1cc7c6f@github.com>
Message-ID: <oGQiEAioLUl1ZawSKWIj9hT4IbxHU8Erl7VI5wf7TAc=.7f3ce360-1668-4a26-8c4a-ed23d1a72923@github.com>

On Mon, 3 Mar 2025 12:27:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
>> 
>> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reading to writing

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23038#pullrequestreview-2655464329

From dholmes at openjdk.org  Tue Mar  4 04:22:56 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 04:22:56 GMT
Subject: RFR: 8350771: Fix -Wzero-as-null-pointer-constant warning in
 nsk/monitoring ThreadController utilitiy
In-Reply-To: <8XY_mw7_i4bOOUHUB2QUPWIddYAXGNFl5gH92SfIEVA=.6c943b2e-8a7f-4b3e-bcce-33010be89f05@github.com>
References: <8XY_mw7_i4bOOUHUB2QUPWIddYAXGNFl5gH92SfIEVA=.6c943b2e-8a7f-4b3e-bcce-33010be89f05@github.com>
Message-ID: <bK0xi-gcfGt3w2-DoYf3jgmQlbsEtuK-KVs2kWfCq3E=.81baa2c5-e7f3-4687-a9bb-bc74dd7fc2f6@github.com>

On Wed, 26 Feb 2025 12:23:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove a use of literal zero as a null
> pointer constant in an nsk test utility.
> 
> Testing: mach5 tier1
> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
> verify the warnings associated with this code were removed.

Looks good and trivial. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23800#pullrequestreview-2655887064

From kbarrett at openjdk.org  Tue Mar  4 04:30:01 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Mar 2025 04:30:01 GMT
Subject: RFR: 8350771: Fix -Wzero-as-null-pointer-constant warning in
 nsk/monitoring ThreadController utility
In-Reply-To: <bK0xi-gcfGt3w2-DoYf3jgmQlbsEtuK-KVs2kWfCq3E=.81baa2c5-e7f3-4687-a9bb-bc74dd7fc2f6@github.com>
References: <8XY_mw7_i4bOOUHUB2QUPWIddYAXGNFl5gH92SfIEVA=.6c943b2e-8a7f-4b3e-bcce-33010be89f05@github.com>
 <bK0xi-gcfGt3w2-DoYf3jgmQlbsEtuK-KVs2kWfCq3E=.81baa2c5-e7f3-4687-a9bb-bc74dd7fc2f6@github.com>
Message-ID: <rnFaqKVfrbQtts_m34B3Bf9Mxce0yE5QNLhUuLy0PS4=.20e4c51f-a974-4231-8232-27bfe02c8056@github.com>

On Tue, 4 Mar 2025 04:20:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this trivial change to remove a use of literal zero as a null
>> pointer constant in an nsk test utility.
>> 
>> Testing: mach5 tier1
>> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
>> verify the warnings associated with this code were removed.
>
> Looks good and trivial. Thanks

Thanks for reviewing @dholmes-ora

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

PR Comment: https://git.openjdk.org/jdk/pull/23800#issuecomment-2696158201

From kbarrett at openjdk.org  Tue Mar  4 04:30:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Mar 2025 04:30:02 GMT
Subject: Integrated: 8350771: Fix -Wzero-as-null-pointer-constant warning in
 nsk/monitoring ThreadController utility
In-Reply-To: <8XY_mw7_i4bOOUHUB2QUPWIddYAXGNFl5gH92SfIEVA=.6c943b2e-8a7f-4b3e-bcce-33010be89f05@github.com>
References: <8XY_mw7_i4bOOUHUB2QUPWIddYAXGNFl5gH92SfIEVA=.6c943b2e-8a7f-4b3e-bcce-33010be89f05@github.com>
Message-ID: <64LiCTntXsrwzPgLWvY729ETJ_JnCLfwAqNkNRpmlH8=.ccc2e4b8-a1b9-441d-b9cd-fdc228c91310@github.com>

On Wed, 26 Feb 2025 12:23:16 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove a use of literal zero as a null
> pointer constant in an nsk test utility.
> 
> Testing: mach5 tier1
> Locally tested (linux-x64) with -Wzero-as-null-pointer-constant enabled to
> verify the warnings associated with this code were removed.

This pull request has now been integrated.

Changeset: d9b98f72
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9b98f72c29f9cf8828fbd33799378bc6b9bfc08
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8350771: Fix -Wzero-as-null-pointer-constant warning in nsk/monitoring ThreadController utility

Reviewed-by: dholmes

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

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

From dholmes at openjdk.org  Tue Mar  4 06:42:51 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 06:42:51 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
Message-ID: <L5t_VF88IOIcKH4ddvExlZTaOonfY4pjcGDHI1zCAH8=.51b89608-1790-4cb2-a87b-0aad737b445a@github.com>

On Mon, 3 Mar 2025 17:08:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> (the last sentence quoted there seems to contradict the first)

I think it is a typo and meant to say `_snprintf` not `snprintf`. I added feedback to the MS page.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2696371535

From dholmes at openjdk.org  Tue Mar  4 06:47:52 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 06:47:52 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

Fix looks good. Thanks.

src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 296:

> 294: /* PDH format patterns, and lengths of their constant component. */
> 295: static const char* const OBJECT_COUNTER_FMT = "\\%s\\%s";
> 296: static const size_t OBJECT_COUNTER_FMT_LEN = 2;

Pre-existing but as per earlier discussions on this, what exactly do these lengths mean??

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23861#pullrequestreview-2656144269
PR Review Comment: https://git.openjdk.org/jdk/pull/23861#discussion_r1978719502

From mbaesken at openjdk.org  Tue Mar  4 08:15:01 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 4 Mar 2025 08:15:01 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
Message-ID: <mSCoKo9abZps8mMeZU92lpGwH26lscp_cY-tvB6uVFk=.1c492ffe-4108-42cc-8fe1-d3e9047f6e82@github.com>

On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright headers

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2656386374

From kevinw at openjdk.org  Tue Mar  4 08:17:53 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 4 Mar 2025 08:17:53 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>
Message-ID: <tRS8nXSiNPpKbzli7P63lpKCKpJFpJxZhSQT3pv41kk=.1af756e4-3fc7-4780-990d-7a8d1f9ec893@github.com>

On Tue, 4 Mar 2025 06:42:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
>> 
>> This change moves to snprintf again, but the counter names are not truncated.
>> 
>> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).
>
> src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 296:
> 
>> 294: /* PDH format patterns, and lengths of their constant component. */
>> 295: static const char* const OBJECT_COUNTER_FMT = "\\%s\\%s";
>> 296: static const size_t OBJECT_COUNTER_FMT_LEN = 2;
> 
> Pre-existing but as per earlier discussions on this, what exactly do these lengths mean??

Yes was trying to clarify that with the comment: the "constant component", the number of fixed characters.  So allocation size is e.g. OBJECT_COUNTER_FMT_LEN (==2) to account for the two backslashes in that format, plus the lengths of the two strings, plus the terminator.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23861#discussion_r1978858171

From duke at openjdk.org  Tue Mar  4 11:22:06 2025
From: duke at openjdk.org (duke)
Date: Tue, 4 Mar 2025 11:22:06 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
Message-ID: <rzz2hqO1c3VbHiwQRTXimIarvn2at8U5FKg0GTy-qEM=.1b50e461-a84a-436b-ada9-a40e0387e280@github.com>

On Fri, 28 Feb 2025 20:40:37 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright headers

@sercher 
Your change (at version bae78ff7c43e0446ef583db1c43b4a3d6c06ad4f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2697178573

From dholmes at openjdk.org  Tue Mar  4 11:50:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 4 Mar 2025 11:50:54 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <tRS8nXSiNPpKbzli7P63lpKCKpJFpJxZhSQT3pv41kk=.1af756e4-3fc7-4780-990d-7a8d1f9ec893@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <vfwOH-BGOlDMiFZfW0X_ctu33FAzhgf7eo6zDurnSdE=.1b2368e6-c19f-49ae-b4ac-bd0238f2a68c@github.com>
 <tRS8nXSiNPpKbzli7P63lpKCKpJFpJxZhSQT3pv41kk=.1af756e4-3fc7-4780-990d-7a8d1f9ec893@github.com>
Message-ID: <uz2jUM_w0vivU16ycywVvc-Qjien1shWZLXjUC4o2Fg=.24ff5b77-98b0-4ea9-ba57-3698be5765c7@github.com>

On Tue, 4 Mar 2025 08:14:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.management/windows/native/libmanagement_ext/OperatingSystemImpl.c line 296:
>> 
>>> 294: /* PDH format patterns, and lengths of their constant component. */
>>> 295: static const char* const OBJECT_COUNTER_FMT = "\\%s\\%s";
>>> 296: static const size_t OBJECT_COUNTER_FMT_LEN = 2;
>> 
>> Pre-existing but as per earlier discussions on this, what exactly do these lengths mean??
>
> Yes was trying to clarify that with the comment: the "constant component", the number of fixed characters.  So allocation size is e.g. OBJECT_COUNTER_FMT_LEN (==2) to account for the two backslashes in that format.  The lengths of the two strings, plus the terminator, are added in the method that constructs the counter path..

Ah! Makes sense now. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23861#discussion_r1979271076

From coleenp at openjdk.org  Tue Mar  4 13:02:06 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 13:02:06 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs
Message-ID: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>

Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
Tested with SA tests locally.

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

Commit messages:
 - 8351165: Remove unused includes from vmStructs

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

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

From coleenp at openjdk.org  Tue Mar  4 13:14:31 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 13:14:31 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v2]
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <XN5l6cr1U8g6vP2b_lDoFr5X5mZvAchjLcfmG3vM6fo=.3ac36468-07f8-4bcd-9058-9b81db8101a1@github.com>

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  One more.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23897/files
  - new: https://git.openjdk.org/jdk/pull/23897/files/c66907b6..e33d5066

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

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

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

From coleenp at openjdk.org  Tue Mar  4 13:22:24 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 13:22:24 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v3]
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Change the SystemDictionary section header comment too.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23897/files
  - new: https://git.openjdk.org/jdk/pull/23897/files/e33d5066..86443005

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

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

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

From kbarrett at openjdk.org  Tue Mar  4 14:33:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 4 Mar 2025 14:33:57 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v3]
In-Reply-To: <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>
Message-ID: <y-1m0EtjTMtHJFGjx2lrEBpk-_s6Tk5qV1es8zOWIXw=.88ad6135-36cc-4a06-9c5b-ab2dbf524be4@github.com>

On Tue, 4 Mar 2025 13:22:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
>> Tested with SA tests locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the SystemDictionary section header comment too.

I think that if classes are being removed from here that the friendship with
VMStructs by those classes should also be removed.

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23897#pullrequestreview-2657808981

From coleenp at openjdk.org  Tue Mar  4 16:40:13 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 16:40:13 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v4]
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <Xgu8UIwABLb2fgRaWTmwNIK-2SkENTjFIwbYjcOp0uY=.ec2d752c-464f-4d48-8be7-8d0c50e97ba7@github.com>

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove some friends.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23897/files
  - new: https://git.openjdk.org/jdk/pull/23897/files/86443005..f2bb9364

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

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

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

From coleenp at openjdk.org  Tue Mar  4 16:44:52 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 4 Mar 2025 16:44:52 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v3]
In-Reply-To: <y-1m0EtjTMtHJFGjx2lrEBpk-_s6Tk5qV1es8zOWIXw=.88ad6135-36cc-4a06-9c5b-ab2dbf524be4@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <ACQWDRy0JGkwOnfNEs9eLA47TGmt1nPBqcGfBeNhdjQ=.fcd745a1-9741-4e08-9a3a-bb0e742b2b74@github.com>
 <y-1m0EtjTMtHJFGjx2lrEBpk-_s6Tk5qV1es8zOWIXw=.88ad6135-36cc-4a06-9c5b-ab2dbf524be4@github.com>
Message-ID: <SDTfCo4DMRTHCqHbW_9_D9Jyx_LTs21Y9RMBCuP90Q8=.e1550a6e-3444-4d0f-ae0e-1c62a28da0e8@github.com>

On Tue, 4 Mar 2025 14:30:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I think that if classes are being removed from here that the friendship with
VMStructs by those classes should also be removed.

Good point.  Thanks for remembering these.

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

PR Comment: https://git.openjdk.org/jdk/pull/23897#issuecomment-2698293824

From alanb at openjdk.org  Tue Mar  4 19:08:55 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Mar 2025 19:08:55 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK
In-Reply-To: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
Message-ID: <prYGzfUmCBunysZ8Nb4yiTx0f0ayjgXHBC3Bdbpgw5Q=.8fe9560b-0987-4c41-96e3-7c095046334b@github.com>

On Sat, 22 Feb 2025 03:31:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in following tests to not check for shared libraries when running on static JDK:
> 
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java

I'm not familiar with details of the output from the System.map command but the change looks reasonable, hopefully @tstuefe or someone familar with this command and these tests can review.

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

PR Comment: https://git.openjdk.org/jdk/pull/23734#issuecomment-2698631487

From schernyshev at openjdk.org  Wed Mar  5 10:35:14 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 5 Mar 2025 10:35:14 GMT
Subject: Integrated: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <ZQH-mksU79ohGcjBhaTu5GclLtV1cftF-wAiWQazxco=.90f7e782-010c-4da6-bfeb-4e8d53c4d0f1@github.com>

On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

This pull request has now been integrated.

Changeset: de29ef3b
Author:    Sergey Chernyshev <schernyshev at openjdk.org>
Committer: Dmitry Chuyko <dchuyko at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de29ef3bf3a029f99f340de9f093cd20544217fd
Stats:     491 lines in 9 files changed: 449 ins; 3 del; 39 mod

8343191: Cgroup v1 subsystem fails to set subsystem path

Co-authored-by: Severin Gehwolf <sgehwolf at openjdk.org>
Reviewed-by: sgehwolf, mbaesken

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

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

From jsjolen at openjdk.org  Wed Mar  5 15:27:14 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 5 Mar 2025 15:27:14 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com>
Message-ID: <O9u-iH-dJXPzONXQCpaCnyNwgJlg1Lq8yBNJbueVzuU=.2461f8fd-d17b-4a1d-95bc-1ea79ecd91ca@github.com>

On Thu, 6 Feb 2025 20:23:32 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback - test

Hi,

Thanks for waiting.

I understand, I think, more or less what this does on the VM side now. I think that we can simplify the code for the cases when we set an error and don't write any error message.

src/hotspot/os/posix/attachListener_posix.cpp line 150:

> 148:   }
> 149: 
> 150:   void complete(jint res, bufferedStream* st) override;

Style: Put brackets together `{}`

src/hotspot/os/posix/attachListener_posix.cpp line 152:

> 150:   void complete(jint res, bufferedStream* st) override;
> 151: 
> 152:   virtual ReplyWriter* get_reply_writer() override {

Style: No need for both `virtual` and `override`.

src/hotspot/os/windows/attachListener_windows.cpp line 128:

> 126:     if (!fSuccess) {
> 127:       log_error(attach)("pipe write error (%d)", GetLastError());
> 128:       return -1;

Style wish: Could you rename `fSuccess` to something like  `write_success`?

src/hotspot/os/windows/attachListener_windows.cpp line 159:

> 157:   void complete(jint result, bufferedStream* result_stream) override;
> 158: 
> 159:   virtual ReplyWriter* get_reply_writer() override {

Style: virtual && override unnecessary

src/hotspot/share/services/attachListener.cpp line 63:

> 61: class attachStream : public bufferedStream {
> 62:   AttachOperation::ReplyWriter* _reply_writer;
> 63:   bool _allow_streaming;

Is this `const`?

src/hotspot/share/services/attachListener.cpp line 66:

> 64:   jint _result;
> 65:   bool _result_set;
> 66:   bool _result_written;

It seems like `_result_written` implies `_result_set`? You can do this:

```c++
enum class ResultState { Unset; Set; Written; };
ResultState _result_state;
jint _result;


And then have the `ResultState` transition from `Unset` to `Set` to `Written`.

src/hotspot/share/services/attachListener.cpp line 137:

> 135:       if (!_error) {
> 136:         _error = !_reply_writer->write_fully(str, (int)len);
> 137:       }

What happens if we're in  `is_streaming()` but the result isn't written? That breaks the protocol. At least add an assert that `_result_written` is set to true.

src/hotspot/share/services/attachListener.cpp line 213:

> 211: }
> 212: 
> 213: static void get_properties(AttachOperation* op, attachStream* out, Symbol* serializePropertiesMethod) {

In this function you have to remember to set the result, otherwise you'll accidentally drop the result. If you return `jint`, you're forced to remember to write a  `return`.

I'd say that you should revert the changes for this function, and instead have the callers of this method set the result code.

In fact, revert this kind of change for all functions in `AttachOperationFunctionInfo funcs[]` and have all send the return code. That simplifies the pattern significantly, as you only need to set the result early if you want to be streaming your output. That also minimizes the changeset, win-win.

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

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2660667054
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981124805
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981125292
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981131134
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981131731
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981377287
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981373628
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981629725
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1981584499

From kbarrett at openjdk.org  Wed Mar  5 19:06:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 5 Mar 2025 19:06:53 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v5]
In-Reply-To: <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
Message-ID: <d6ZtXHTWxJPfr12XYfeRgovnLEeyzaz-v3GEpXEOQ3M=.0a5b2abc-a5b6-4b7d-8819-9be34fde3cfe@github.com>

On Tue, 4 Mar 2025 23:00:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
>> Tested with SA tests locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove more friends.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23897#pullrequestreview-2662217792

From lmesnik at openjdk.org  Wed Mar  5 19:28:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 5 Mar 2025 19:28:52 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <fpCcbOjE8dvzLxKqEChz8h4kFJi9xjjd3LOSYnYhyhg=.10d26264-4269-467b-a830-213ded93cd40@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

I assume you tested the changes, even tests are problemlisted now.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23861#pullrequestreview-2662279073

From coleenp at openjdk.org  Wed Mar  5 19:31:57 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Mar 2025 19:31:57 GMT
Subject: RFR: 8351165: Remove unused includes from vmStructs [v5]
In-Reply-To: <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
 <8j8Q9lFaUqpJ-00YvaTbQpsR_mP3r6hukpeWiqss1yk=.0995063a-99d9-4b86-ab99-1b38f387a8a8@github.com>
Message-ID: <5H2L7HiXE3L6CDr_OQl5nG6axx6KD2F36rwTzLBwNoM=.273f0844-98de-423c-a298-aa3f65adc44f@github.com>

On Tue, 4 Mar 2025 23:00:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
>> Tested with SA tests locally.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove more friends.

Thanks Kim.  I'm going to continue to claim this is trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/23897#issuecomment-2701871901

From coleenp at openjdk.org  Wed Mar  5 19:31:58 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 5 Mar 2025 19:31:58 GMT
Subject: Integrated: 8351165: Remove unused includes from vmStructs
In-Reply-To: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
References: <gP0QWjJCa3nM71Fcnz0822gV1IoYcKe-aRFOV116q84=.0d99b236-76bd-4747-a82a-db24525164b0@github.com>
Message-ID: <8cF_zUKZyH6XE8iGcDsw2x0hUfSy3ZiAAOsgzXXb7dE=.b436e37d-8a2b-4fce-90df-40ec3691a5a4@github.com>

On Tue, 4 Mar 2025 12:56:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove some unneeded includes and type declarations from vmStructs.  The SystemDictionary type is unused because classes are looked up in the ClassLoaderDataGraph in the SA, and they haven't been in a single SystemDictionary for a very long time.
> Tested with SA tests locally.

This pull request has now been integrated.

Changeset: 11a37c82
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/11a37c829c12d064874416a7b242596cf23972e5
Stats:     39 lines in 9 files changed: 0 ins; 32 del; 7 mod

8351165: Remove unused includes from vmStructs

Reviewed-by: kbarrett

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

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

From kevinw at openjdk.org  Wed Mar  5 19:57:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 5 Mar 2025 19:57:57 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <fpCcbOjE8dvzLxKqEChz8h4kFJi9xjjd3LOSYnYhyhg=.10d26264-4269-467b-a830-213ded93cd40@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <fpCcbOjE8dvzLxKqEChz8h4kFJi9xjjd3LOSYnYhyhg=.10d26264-4269-467b-a830-213ded93cd40@github.com>
Message-ID: <23Nz2gLPAuq6m1mGl0CJIhuUW6WQZHvNrYT8pZ4sSnE=.2d28b6df-aa08-4ed5-8214-ebccadd344aa@github.com>

On Wed, 5 Mar 2025 19:26:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I assume you tested the changes, even tests are problemlisted now.

Thanks Leonid, yes tested manually and with the tests.  Will look at the tests and again and see if we can see why they had some failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2701927915

From sspitsyn at openjdk.org  Wed Mar  5 23:36:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 5 Mar 2025 23:36:52 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <L6hV533uGWb4p3xAm0zkmB8H4UAVvkHZ1pFs61tnAF4=.4a7bccf5-b997-44d1-be31-1db5e99b38bf@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23861#pullrequestreview-2662733039

From amenkov at openjdk.org  Thu Mar  6 02:18:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Mar 2025 02:18:35 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v4]
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@github.com>

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23405/files
  - new: https://git.openjdk.org/jdk/pull/23405/files/d074f2f7..5c87f9e4

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

  Stats: 105 lines in 3 files changed: 18 ins; 23 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/23405.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23405/head:pull/23405

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

From amenkov at openjdk.org  Thu Mar  6 02:18:36 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 6 Mar 2025 02:18:36 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v3]
In-Reply-To: <O9u-iH-dJXPzONXQCpaCnyNwgJlg1Lq8yBNJbueVzuU=.2461f8fd-d17b-4a1d-95bc-1ea79ecd91ca@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <4Bmzepx0oatn_NqbrzEdCMEQCBBpPwV1VW7KymjdrUQ=.09ea6870-2d00-4059-acb5-df53b72a25ef@github.com>
 <O9u-iH-dJXPzONXQCpaCnyNwgJlg1Lq8yBNJbueVzuU=.2461f8fd-d17b-4a1d-95bc-1ea79ecd91ca@github.com>
Message-ID: <ZB4efJoqZqUUoPwiW2jFcQshzdntFNUAkfHETmTGJbA=.eec9ac57-4041-4978-85f8-834e1f50029a@github.com>

On Wed, 5 Mar 2025 10:29:21 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback - test
>
> src/hotspot/os/posix/attachListener_posix.cpp line 150:
> 
>> 148:   }
>> 149: 
>> 150:   void complete(jint res, bufferedStream* st) override;
> 
> Style: Put brackets together `{}`

Fixed

> src/hotspot/os/posix/attachListener_posix.cpp line 152:
> 
>> 150:   void complete(jint res, bufferedStream* st) override;
>> 151: 
>> 152:   virtual ReplyWriter* get_reply_writer() override {
> 
> Style: No need for both `virtual` and `override`.

Fixed.

> src/hotspot/os/windows/attachListener_windows.cpp line 128:
> 
>> 126:     if (!fSuccess) {
>> 127:       log_error(attach)("pipe write error (%d)", GetLastError());
>> 128:       return -1;
> 
> Style wish: Could you rename `fSuccess` to something like  `write_success`?

This is general style in the file (I believe it came from MSDN examples), so I prefer to leave it as is for now

> src/hotspot/os/windows/attachListener_windows.cpp line 159:
> 
>> 157:   void complete(jint result, bufferedStream* result_stream) override;
>> 158: 
>> 159:   virtual ReplyWriter* get_reply_writer() override {
> 
> Style: virtual && override unnecessary

Fixed.

> src/hotspot/share/services/attachListener.cpp line 63:
> 
>> 61: class attachStream : public bufferedStream {
>> 62:   AttachOperation::ReplyWriter* _reply_writer;
>> 63:   bool _allow_streaming;
> 
> Is this `const`?

Right. Fixed.

> src/hotspot/share/services/attachListener.cpp line 66:
> 
>> 64:   jint _result;
>> 65:   bool _result_set;
>> 66:   bool _result_written;
> 
> It seems like `_result_written` implies `_result_set`? You can do this:
> 
> ```c++
> enum class ResultState { Unset; Set; Written; };
> ResultState _result_state;
> jint _result;
> 
> 
> And then have the `ResultState` transition from `Unset` to `Set` to `Written`.

Updated

> src/hotspot/share/services/attachListener.cpp line 213:
> 
>> 211: }
>> 212: 
>> 213: static void get_properties(AttachOperation* op, attachStream* out, Symbol* serializePropertiesMethod) {
> 
> In this function you have to remember to set the result, otherwise you'll accidentally drop the result. If you return `jint`, you're forced to remember to write a  `return`.
> 
> I'd say that you should revert the changes for this function, and instead have the callers of this method set the result code.
> 
> In fact, revert this kind of change for all functions in `AttachOperationFunctionInfo funcs[]` and have all send the return code. That simplifies the pattern significantly, as you only need to set the result early if you want to be streaming your output. That also minimizes the changeset, win-win.

Updated as suggested. But github considers diff for the file as "large" :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982500667
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982501693
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982528121
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982502593
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982504691
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982517135
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1982514245

From duke at openjdk.org  Thu Mar  6 10:45:04 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 10:45:04 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
Message-ID: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>

Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.

This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.

Sponsored by: The FreeBSD Foundation
Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>

[1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

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

Commit messages:
 - 8351322: Parameterize link option for pthreads

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

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

From kevinw at openjdk.org  Thu Mar  6 12:30:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 6 Mar 2025 12:30:06 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <puSf7JAHZOAA_J5J8Smo-v4Kzjzr4BetnhKm46VUe6A=.48a8f133-f0c5-4943-bb05-84f035d91a3d@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

Thanks for reviews.
Reran with edited problemlist to run relevant tests, all good.
Hope we can clear problemlist in near future!...

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703704150

From kevinw at openjdk.org  Thu Mar  6 12:30:07 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 6 Mar 2025 12:30:07 GMT
Subject: Integrated: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
Message-ID: <qI6LWYY5HGJjqxvj4nncCLYzZ1bsTgoS3y1jJY0EdzA=.ff994b6d-f336-4698-8683-e2750c81b33b@github.com>

On Mon, 3 Mar 2025 12:22:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JDK-8350820, which backed out the _snprintf to snprintf change (JDK-8336289) in OperatingSystemImpl.c on Windows, because the counter names were being truncated (so CPU monitoring was not possible).
> 
> This change moves to snprintf again, but the counter names are not truncated.
> 
> snprintf must need the null terminator to fit inside the buffer length given.  It does not, and snprintf truncates (and always add the null terminator).

This pull request has now been integrated.

Changeset: 8f8a879d
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f8a879de03add68e385f2610863d3b4ddd86df7
Stats:     41 lines in 1 file changed: 0 ins; 5 del; 36 mod

8350939: Revisit Windows PDH buffer size calculation for OperatingSystemMXBean

Reviewed-by: dholmes, lmesnik, sspitsyn

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

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

From dholmes at openjdk.org  Thu Mar  6 12:49:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 6 Mar 2025 12:49:02 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

Needs build team approval before integrating.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664340896

From jpai at openjdk.org  Thu Mar  6 13:28:12 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 13:28:12 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
Message-ID: <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>

On Mon, 3 Mar 2025 17:08:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> We calculate a size (length of the counter in characters), which might be '\Process(java#0)% Processor Time', 33 chars.

Isn't that 32 characters?

I understood the rest of the explanation in this PR and the change sounds reasonable to me. It's just this character count that I'm unsure about. Is that a typo?

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703849110

From duke at openjdk.org  Thu Mar  6 13:29:55 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 13:29:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
Message-ID: <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>

On Thu, 6 Mar 2025 12:46:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.

I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2703853406

From duke at openjdk.org  Thu Mar  6 13:55:53 2025
From: duke at openjdk.org (Antonio Vieiro)
Date: Thu, 6 Mar 2025 13:55:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/test/JtregNativeHotspot.gmk line 886:

> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
> 885: else
> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)

Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
Could be me too, I need new reading glasses...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983396617

From kevinw at openjdk.org  Thu Mar  6 14:20:06 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 6 Mar 2025 14:20:06 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
 <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>
Message-ID: <5bV2Z1AGdQaiAmeuF6s58UXf2nMRAAaLvwduNUMSx90=.1a63aa64-1092-49b9-b78a-36fa2ac6e883@github.com>

On Thu, 6 Mar 2025 13:25:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Isn't that 32 characters?

Yes thanks well spotted.  Just to clarify, looks like I dropped a backslash while making that note, the counter would look like `'\Process(java#0)% Processor Time' `

8-)

(Correction, I didn't drop a backslash, it's being formatted here in github...)

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703969446

From jpai at openjdk.org  Thu Mar  6 14:20:06 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 6 Mar 2025 14:20:06 GMT
Subject: RFR: 8350939: Revisit Windows PDH buffer size calculation for
 OperatingSystemMXBean
In-Reply-To: <5bV2Z1AGdQaiAmeuF6s58UXf2nMRAAaLvwduNUMSx90=.1a63aa64-1092-49b9-b78a-36fa2ac6e883@github.com>
References: <tvoYl7YLRzo1hgmFzAPG7JUc9Lmz1U0DkECD1m9ShjE=.193f5026-1e0a-44a9-83a8-f5d75ddc120b@github.com>
 <eh8LA6SL75c1LarlNMOLRLU85igOegtQvXwQUIv0Yk8=.cb2abe71-b397-434e-b53e-de3860da6b10@github.com>
 <JSJw8V8mbRMr2dWoWeuOpiNfGVQ3Hsz7T5A8oTfGP_w=.565460eb-a07e-4a3b-9855-a16fecae47c8@github.com>
 <5bV2Z1AGdQaiAmeuF6s58UXf2nMRAAaLvwduNUMSx90=.1a63aa64-1092-49b9-b78a-36fa2ac6e883@github.com>
Message-ID: <1GnM46WdduLt66D1g5nwQyvgyPgEHQHt6BwNoHx3ntA=.129cd53e-c11b-4ccd-8ed5-b07d92535c64@github.com>

On Thu, 6 Mar 2025 14:13:51 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> > Isn't that 32 characters?
> 
> Yes thanks well spotted. Just to clarify, looks like I dropped a backslash while making that note, the counter would look like `'\Process(java#0)% Processor Time' `
> 
> 8-)
> 
> (Correction, I didn't drop a backslash, it's being formatted here in github...)

Thank you Kevin for clarifying. It all looks good and matches what you noted in your description.

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

PR Comment: https://git.openjdk.org/jdk/pull/23861#issuecomment-2703982118

From erikj at openjdk.org  Thu Mar  6 14:23:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 6 Mar 2025 14:23:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?

make/autoconf/libraries.m4 line 142:

> 140:   # Threading library
> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"

If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.

Suggestion:

    BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

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

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2664582520
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983435650

From ihse at openjdk.org  Thu Mar  6 15:51:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:51:52 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
Message-ID: <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>

On Thu, 6 Mar 2025 14:21:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?

This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

Yes, this is incorrect. Remember that m4 are shell scripts so you need to use shell syntax here. (I know it is confusing).

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2704233217
PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983608153

From ihse at openjdk.org  Thu Mar  6 15:58:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

make/Hsdis.gmk line 131:

> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
> 131:   else

The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983621784

From ihse at openjdk.org  Thu Mar  6 15:58:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 15:58:58 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
Message-ID: <oXeR7653mNNaWgQUd8T_KiQM8R987ZCjfuWAWNAoLLU=.a1980e25-ad0d-4da6-9bb2-92c13e790b28@github.com>

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

You're absolutely right. 

@snake66 Making changes to makefiles is tricky, since a misspelled variable do not get any warning but is just silently ignored. 

For a change like this, that is a pure refactoring that is not supposed to change the output, I highly recommend using the `COMPARE_BUILD` system. Unfortunately, this is severely underdocumented. There is a short paragraph at https://openjdk.org/groups/build/doc/building.html under "Developing the Build System Itself", but in short, what I'd do is to create a diff files of these changes compared to a baseline (e.g. master, a specific build or commit), make sure you have the baseline checked out, and then run `make jdk-image test-image COMPARE_BUILD=PATCH=my_patch.diff`. This will build the targets twice, one without the patch and one with the patch, and then automatically run the `compare` script to analyze any differences. For this particular patch, there should be none. This would likely have caught this typo. (Given that the test-image is actually compared; I suddenly got a bit uncertain about that...)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983618250

From duke at openjdk.org  Thu Mar  6 17:21:01 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:21:01 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <UeEosmqNTyn4f5U2d3g4VDt-frBRQias-okA6eBRjUc=.4bdd884f-9ce2-4891-b53e-08fe1b6074d9@github.com>
Message-ID: <1xDhCbB5y6lKeTsljSaXQIctUdhLeZYMZc3ttv3CCAY=.e32e38b6-8431-4fa9-9b49-8fb305a744aa@github.com>

On Thu, 6 Mar 2025 13:53:31 GMT, Antonio Vieiro <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/test/JtregNativeHotspot.gmk line 886:
> 
>> 884:   BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack := java.base:libjvm
>> 885: else
>> 886:   BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libbootclssearch_agent += $(LIBPTREAD)
> 
> Hi. Should this read `$(LIBPTHREAD)` instead (i.e., missing `H`)? 
> Could be me too, I need new reading glasses...

@vieiro Thanks! That's well spotted, I'll fix!

@magicus Thanks for this info! I'll give it a try without fixing the typo first, to see if it would catch it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983764371

From duke at openjdk.org  Thu Mar  6 17:31:53 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MyiXfAfRV3YD5pcrbko2HFjPZSkK7xKI9EE0P8tCUXI=.40d3a8d3-4f72-417c-b9d0-8f7561ea0d2c@github.com>
Message-ID: <vLspqp3iNAf1V1PXvKB4844a1K71STekYMCWeTLLqv8=.ed29364e-71fa-4ca6-83a3-48435263cd3d@github.com>

On Thu, 6 Mar 2025 15:56:43 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/Hsdis.gmk line 131:
> 
>> 129:     HSDIS_TOOLCHAIN_LIBS := $(MINGW_DLLCRT) -lmingw32 -lgcc -lgcc_eh -lmoldname \
>> 130:         -lmingwex -lmsvcrt $(LIBPTHREAD) -ladvapi32 -lshell32 -luser32 -lkernel32
>> 131:   else
> 
> The hsdis build is very weird and outside the normal integrated JDK build. I recommend you leave this instance alone. If you want to port hsdis to BSD you are likely to have to rewrite large parts of the compilation logic here anyway.

Ack, I'll drop that one from the patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983780437

From duke at openjdk.org  Thu Mar  6 17:31:54 2025
From: duke at openjdk.org (snake66)
Date: Thu, 6 Mar 2025 17:31:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
Message-ID: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>

On Thu, 6 Mar 2025 14:15:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> make/autoconf/libraries.m4 line 142:
> 
>> 140:   # Threading library
>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
> 
> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
> 
> Suggestion:
> 
>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"

@erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983779126

From jsjolen at openjdk.org  Thu Mar  6 17:54:56 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 6 Mar 2025 17:54:56 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v4]
In-Reply-To: <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@github.com>
Message-ID: <lqI3Vuwxw6yF7lgDBMsqfTSTfHIO-rzJcciPfcrG-nQ=.88e73f09-797e-4187-bfd5-bf01b97cf70e@github.com>

On Thu, 6 Mar 2025 02:18:35 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

Hi Alex,

I'm generally happy with this code. I've got a few more comments, but nothing major.

src/hotspot/share/services/attachListener.cpp line 316:

> 314: 
> 315: static jint data_dump(AttachOperation* op, attachStream* out) {
> 316:   out->set_result(JNI_OK); // allow streaming output

I'm wondering, do you think it's useful to add a helper `start_streaming_if_available` (or whatever) that just calls `set_result(JNI_OK)`? That helper could have a small snippet of documentation to explain what's going on. That would probably be neater than a comment.

src/hotspot/share/services/attachListener.cpp line 373:

> 371:   // The commands report error if the agent failed to load, so we need to disable streaming output.
> 372:   const char jmx_prefix[] = "ManagementAgent.";
> 373:   if (strncmp(op->arg(0), jmx_prefix, strlen(jmx_prefix)) == 0) {

`const char* jmx_prefix = "ManagementAgent.", not array.

src/hotspot/share/services/attachListener.cpp line 396:

> 394:   if (HAS_PENDING_EXCEPTION) {
> 395:     // We can get an exception during command execution.
> 396:     // In the case _attach_stream->set_result() is already called and operation result code is send

"is senT to the client"

src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 379:

> 377: 
> 378:             // Reply is "<ver> option1,option2...".
> 379:             int delimPos = message.indexOf(' ');

We can do this in an early-break sort of way. That'd reduce the indentation and let's us not to have to check `delimPos` again.


int delimPos = message.indexOf(' ');
int supportedVersion = Integer.parseUnsignedInt(delimPos < 0 ? message : message.substring(0, delimPos));
if (delimPos < 0 || supportedVersion != VERSION_2) {
    return; // No options to parse, or doesn't support options anyway
}
/* Insert the parsing stuff here */

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

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2665162130
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983778660
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983782768
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983783438
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1983812437

From ihse at openjdk.org  Thu Mar  6 18:24:05 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 6 Mar 2025 18:24:05 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <54EZ9lj24GmFRpw6WevTMzIJUr9g_hzrJ-IBtw5OGCw=.2822aace-3682-490b-b47d-309943df311c@github.com>
Message-ID: <8oD1j-gxmzv2_5BOV5GohhkiKcuTDqxAC-3mnF8i-3o=.f2d870af-a508-4b53-95ac-d886fdc21b09@github.com>

On Thu, 6 Mar 2025 17:28:10 GMT, snake66 <duke at openjdk.org> wrote:

>> make/autoconf/libraries.m4 line 142:
>> 
>>> 140:   # Threading library
>>> 141:   if test "x$OPENJDK_TARGET_OS" = xlinux || test "x$OPENJDK_TARGET_OS" = xaix; then
>>> 142:     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $(LIBPTHREAD)"
>> 
>> If you specifically need this to be resolved in the makefile rather than here, then please add a comment explaining why, otherwise use a shell script variable reference.
>> 
>> Suggestion:
>> 
>>     BASIC_JVM_LIBS="$BASIC_JVM_LIBS $LIBPTHREAD"
>
> @erikj79 There will be a later patch to libraries.m4 that sets the variable based on the target platform, and then populates the `LIBPTHREAD` variable in spec.gmk. (https://github.com/openjdk/jdk/pull/23930/files#diff-56172cd2ec5804a5f764a6d0d5970da6144b024a06e008571f9822b2dc83cc36R147) That means the parenthesis should stay, right?

I'm not sure what you mean now. The link is to this very patch, which does what you describe -- sets LIBPTHREAD according to OS and stores it in spec.gmk.

And no, the paranthesis should not stay. If you keep them, the variable will be re-evaluated in make every time BASIC_JVM_LIBS is evaluated. That is not needed; by dropping the parenthesis the actual value to be used will be inserted as a string constant. Which is what we want, since we know the value at configure time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23930#discussion_r1983853576

From dholmes at openjdk.org  Fri Mar  7 00:20:57 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 00:20:57 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
Message-ID: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>

On Thu, 6 Mar 2025 15:47:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> What is the intended way of using this? Do you run make with `LIBPTHREAD=-pthread` or do you apply a patch on `libraries.m4` for the specific way of linking to pthread?
>
>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
> 
> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.

@magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2705227213

From amenkov at openjdk.org  Fri Mar  7 01:46:37 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Mar 2025 01:46:37 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v5]
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <oJjAjXaPQgDh7AYdSDzC3vPbxA669H68ZlbjfyLeDUo=.06dd0b2d-6428-4da4-aa8c-7c0c14d26c9d@github.com>

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23405/files
  - new: https://git.openjdk.org/jdk/pull/23405/files/5c87f9e4..2a3d4346

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

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

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

From amenkov at openjdk.org  Fri Mar  7 02:15:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 7 Mar 2025 02:15:56 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v4]
In-Reply-To: <lqI3Vuwxw6yF7lgDBMsqfTSTfHIO-rzJcciPfcrG-nQ=.88e73f09-797e-4187-bfd5-bf01b97cf70e@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <2VrvagcQ_c6vqMMaINqJ-DNTnXB_c8eAW4qo_yvtcvE=.ac41a25f-7e74-4bfd-9a85-bd7bd5ef7083@github.com>
 <lqI3Vuwxw6yF7lgDBMsqfTSTfHIO-rzJcciPfcrG-nQ=.88e73f09-797e-4187-bfd5-bf01b97cf70e@github.com>
Message-ID: <fme883PAlbdETWn2f4DCVn5CEu1W30vMIrNoH9RKPhU=.c5491fe7-61da-467f-91d9-c096e82ce499@github.com>

On Thu, 6 Mar 2025 17:27:56 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> src/hotspot/share/services/attachListener.cpp line 316:
> 
>> 314: 
>> 315: static jint data_dump(AttachOperation* op, attachStream* out) {
>> 316:   out->set_result(JNI_OK); // allow streaming output
> 
> I'm wondering, do you think it's useful to add a helper `start_streaming_if_available` (or whatever) that just calls `set_result(JNI_OK)`? That helper could have a small snippet of documentation to explain what's going on. That would probably be neater than a comment.

I don't think helper method is needed (and those comments too :)
I think the better approach would be "operation handler should call set_result as soon as it knows the result code"

> src/hotspot/share/services/attachListener.cpp line 373:
> 
>> 371:   // The commands report error if the agent failed to load, so we need to disable streaming output.
>> 372:   const char jmx_prefix[] = "ManagementAgent.";
>> 373:   if (strncmp(op->arg(0), jmx_prefix, strlen(jmx_prefix)) == 0) {
> 
> `const char* jmx_prefix = "ManagementAgent.", not array.

Fixed.

> src/hotspot/share/services/attachListener.cpp line 396:
> 
>> 394:   if (HAS_PENDING_EXCEPTION) {
>> 395:     // We can get an exception during command execution.
>> 396:     // In the case _attach_stream->set_result() is already called and operation result code is send
> 
> "is senT to the client"

Fixed

> src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line 379:
> 
>> 377: 
>> 378:             // Reply is "<ver> option1,option2...".
>> 379:             int delimPos = message.indexOf(' ');
> 
> We can do this in an early-break sort of way. That'd reduce the indentation and let's us not to have to check `delimPos` again.
> 
> 
> int delimPos = message.indexOf(' ');
> int supportedVersion = Integer.parseUnsignedInt(delimPos < 0 ? message : message.substring(0, delimPos));
> if (delimPos < 0 || supportedVersion != VERSION_2) {
>     return; // No options to parse, or doesn't support options anyway
> }
> /* Insert the parsing stuff here */

To me current implementation looks clearer. And I think it will be simpler to extend the logic (if we ever need to extend v2 or introduce v3)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984330438
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984331040
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984332637
PR Review Comment: https://git.openjdk.org/jdk/pull/23405#discussion_r1984343797

From dholmes at openjdk.org  Fri Mar  7 04:37:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 7 Mar 2025 04:37:09 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
 <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
Message-ID: <YB0BPE3YrgPXxXVz-kiybyCy115iGXumKpyaw1-AcEs=.d0ec39ec-b697-4ada-b19e-bad218c0d4d2@github.com>

On Sun, 2 Mar 2025 21:17:04 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
>
>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
> 
> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.

@sercher  your new test is failing in our CI:

[STDOUT]
mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory

I will file a new bug

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2705506729

From ihse at openjdk.org  Fri Mar  7 11:34:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 11:34:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <ZF1daFkBTlQ8lrEMRD3alDurQiOp02Q-5YYJ822f0GE=.24d747ef-9efe-497f-b792-58850aff5467@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

@dholmes-ora Good question. I don't know the answer. I know we used `-pthread` exclusively on Solaris, and that we've used `-lpthread` on Linux (but apparently not in all cases?). I guess this difference would not have been introduced when the Linux port was created from the Solaris port unless it made sense. So maybe at that time, GCC did not support `-pthread`. Otoh, that might have changed by now.

Regardless, I would still like to see this change. We have generalized almost all system libraries to variable (like `$LIBM`, `$LIBDL` etc), and this is the last remaining (I think).

We can then check if we can turn `-lpthread` into `-pthread` on Linux as a follow up.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2706220845

From kevinw at openjdk.org  Fri Mar  7 13:58:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 7 Mar 2025 13:58:59 GMT
Subject: Integrated: 8347433: Deprecate XML interchange in
 java.management/javax/management/modelmbean/DescriptorSupport for removal
In-Reply-To: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
References: <9N1A-f0MIuQ28ovLQzwroR8FLHxc5raDLS7MdQ40wkg=.07d2f0ca-9055-44ce-97e0-af3ee52dbf9d@github.com>
Message-ID: <zilAEjIBs6ZwOKLB0DEQW3C795MrNuH8m9PIQUWIfso=.87602912-3b5e-413e-af5d-a160806b2c3f@github.com>

On Fri, 10 Jan 2025 14:43:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> DescriptorSupport has a constructor and a method providing creation from, and export to, XML.
> 
> These are unused in the JDK and have no practical known examples of usage.  XML parsing is best done by an independent implementation, not this class.

This pull request has now been integrated.

Changeset: 54fe643e
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/54fe643e783befb4d215c68e4b1fed351d470435
Stats:     29 lines in 3 files changed: 19 ins; 3 del; 7 mod

8347433: Deprecate XML interchange in java.management/javax/management/modelmbean/DescriptorSupport for removal

Reviewed-by: sspitsyn, dfuchs

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

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

From ihse at openjdk.org  Fri Mar  7 15:19:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 7 Mar 2025 15:19:07 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
 <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
Message-ID: <7lj62NHzOSzqL-1MEvHLg228x2l3rVABVe8weAnA-EQ=.ed5dba84-190a-4204-b80c-b23be62a9dc5@github.com>

On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
>> 
>> Tested on static JDK locally
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161
>
> Thanks for the reviews and historical info!

@jianglizhou I looked at this as part of my backlog, and it struck me that there are several other tests that declare a dependency to java.base:libjvm. Are these working properly on static builds?

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2706710853

From jiangli at openjdk.org  Fri Mar  7 18:33:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 7 Mar 2025 18:33:57 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
 <gRfO3DYkPXdUSjnFbT1hUfDdOmzwiyx4mCAm7K2t_tY=.b5c00109-0687-46a6-a0dc-ddb6115b4cbf@github.com>
Message-ID: <Nb4lfm2dNfX3WmFghQr776Qv3NrsYOPrMIGwDgmDwJ4=.161c11d8-0ae8-46a6-bd33-b29dcbffc625@github.com>

On Mon, 3 Mar 2025 17:36:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
>> 
>> Tested on static JDK locally
>> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161
>
> Thanks for the reviews and historical info!

> @jianglizhou I looked at this as part of my backlog, and it struck me that there are several other tests that declare a dependency to java.base:libjvm. Are these working properly on static builds?

Except `BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack`, the other remaining ones in [JtregNativeJdk.gmk](https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/make/test/JtregNativeJdk.gmk#L56),  [JtregNativeLibTest.gmk](https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/make/test/JtregNativeLibTest.gmk#L48) and [JtregNativeHotspot.gmk](https://github.com/openjdk/jdk/blob/5cd4fe63768715ec7be32e248e05e611ea9b557d/make/test/JtregNativeHotspot.gmk#L858) with `java.base:libjvm` dependency are for building test `exe`. We could skip those tests on static JDK until we figure out how we want to support multiple executables. 

`BUILD_HOTSPOT_JTREG_LIBRARIES_JDK_LIBS_libnativeStack` adds `java.base:libjvm` dependency on Windows only. It might not be needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2707127984

From schernyshev at openjdk.org  Fri Mar  7 20:22:04 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 7 Mar 2025 20:22:04 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
 [v17]
In-Reply-To: <YB0BPE3YrgPXxXVz-kiybyCy115iGXumKpyaw1-AcEs=.d0ec39ec-b697-4ada-b19e-bad218c0d4d2@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <CNqGxWaGlz2X6DAr2lbhq5mGILZslfsnfBqQaH7sikU=.dc159c49-5ab8-46ed-9c7b-091a1f3dd078@github.com>
 <iqYDDABcao2jEjpXBj4DMvLnvwhapySBhrUeztEPQ2A=.4e672019-adf6-4c16-96ed-92492f48df69@github.com>
 <P5D4hsLIDsmxbnTZlQBTZrNJ6RvJBw59Jns1WAuK8EE=.6ef5b91a-34db-4bb9-bc0b-b7a04bc0a933@github.com>
 <YB0BPE3YrgPXxXVz-kiybyCy115iGXumKpyaw1-AcEs=.d0ec39ec-b697-4ada-b19e-bad218c0d4d2@github.com>
Message-ID: <deDJZA73L8kTydeDVemXCML9guQmHHHrkFiUmlZB_dU=.aa941441-2270-4c5f-aab8-fc34fc9e0167@github.com>

On Fri, 7 Mar 2025 04:34:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> OK for me now. `test_cgroupSubsystem_linux.cpp` needs a copyright update as well.
>> 
>> Thanks for your review @jerboaa ! I cheched the test_cgroupSubsystem_linux.cpp, it's already updated to 2025 in the master branch.
>
> @sercher  your new test is failing in our CI:
> 
> [STDOUT]
> mkdir: cannot create directory '/sys/fs/cgroup/memory/test': Permission denied
> sh: /sys/fs/cgroup/memory/test/memory.limit_in_bytes: No such file or directory
> sh: /sys/fs/cgroup/memory/test/cgroup.procs: No such file or directory
> 
> I will file a new bug - [JDK-8351382](https://bugs.openjdk.org/browse/JDK-8351382)

@dholmes-ora I submitted a fix [here](https://github.com/openjdk/jdk/pull/23948). Could you please re-run the tests in your CI?

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2707344030

From duke at openjdk.org  Sat Mar  8 13:39:44 2025
From: duke at openjdk.org (snake66)
Date: Sat, 8 Mar 2025 13:39:44 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

snake66 has updated the pull request incrementally with three additional commits since the last revision:

 - Use shell var syntax in libraries.m4
 - Fix typo PTREAD->PTHREAD
 - Revert changes to make/Hsdis.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23930/files
  - new: https://git.openjdk.org/jdk/pull/23930/files/6a2c0e53..46999723

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

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

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

From jwaters at openjdk.org  Sun Mar  9 18:30:01 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 9 Mar 2025 18:30:01 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <6n7W6MsSzG06DWdin8ZYslKSPueuSMB0l5s6hQb2DPg=.f10d6056-9560-4835-8380-0b54df417426@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Keep open please. I will integrate this as soon as possible when I get approval for all the respective Pull Requests

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2709003672

From ihse at openjdk.org  Mon Mar 10 11:09:54 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <fW2QbW1i6Z-yKZaK2UhG5fn-SMbZ7QbX0DQQ4KC4x4w=.85a1740c-d82d-4681-bebf-bc5961a47c3c@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

Another follow-up is if it would hurt to include $LIBPTHREAD for *all* Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710217007

From ihse at openjdk.org  Mon Mar 10 11:09:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:09:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <2Q8X64gNkTwIahuYztjcdmNpOiwF9imTIUUI-0ASx4k=.4ba096ff-d60b-46fd-93ce-33215b0bc650@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

This looks good now. Thanks!

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670569844

From ihse at openjdk.org  Mon Mar 10 11:13:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 11:13:02 GMT
Subject: RFR: 8350903: Remove explicit libjvm.so dependency for
 libVThreadEventTest
In-Reply-To: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
References: <bXqR8hmfO6RxtrjB2dDW0ejt4n0TKb4c2dV1_ogGCks=.b2133424-e249-45aa-b3da-9a421f25d210@github.com>
Message-ID: <xkrLjELwIEqijtebFGcQzVvj5pIManAq7LrAAkQAJ6k=.b56fc428-c733-4878-8d28-39d7a9063e27@github.com>

On Fri, 28 Feb 2025 01:40:34 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the test fix that removes `libVThreadEventTest` explicit dependency to `libjvm`, by removing the call to `JNI_GetCreatedJavaVMs` in `Agent_OnAttach`. There is a `vm` argument passed via `Agent_OnAttach`. With the change, `libVThreadEventTest` no longer needs to be linked with `libjvm.so` (or `jvm.dll`). `VThreadEventTest.java` now runs on both dynamic and static JDK.
> 
> Tested on static JDK locally
> GHA: https://github.com/jianglizhou/jdk/actions/runs/13577993687/job/37960245161

Okay, great! I did not notice it was for exe's, I just grepped quickly for `libjvm`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23835#issuecomment-2710224648

From erikj at openjdk.org  Mon Mar 10 13:04:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 13:04:54 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <9NJh2NWuQ_op9oUEpq2qS-64TpkGnIXaT54pdIV8amI=.e65c76d6-bb81-4ce0-b3ee-5d8c975b6ac5@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23930#pullrequestreview-2670880262

From ihse at openjdk.org  Mon Mar 10 13:48:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 10 Mar 2025 13:48:53 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <MgjeMwVfZU6jWsDi4eNnu-lLA2teG82qmq62bCr2Vlo=.b2a4a9e4-43df-4409-9489-416082c3e6a8@github.com>
 <EQkgo0IHcPunD6ia6wSB_AMGlm3fHJuxAsl9MHAzX1U=.f25212d1-4ddb-4665-ae06-0040c28b2146@github.com>
Message-ID: <g2XMt1vhpaPef9D_78B-x4Rn-hOQeSrBgyK2LJnTo2w=.5d1450d9-8fa0-4cbc-ade5-1a02e20a0250@github.com>

On Thu, 6 Mar 2025 13:27:15 GMT, snake66 <duke at openjdk.org> wrote:

>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
>> 
>> Needs build team approval before integrating.
>
>> Abstracting this out seems reasonable to me, though I should say I thought we already used `-pthread` rather than `-lpthread`.
> 
> I noticed there were a few places that used `-pthread` by default. I left these alone in this PR.

@snake66 To integrate this, you need to give the command `/integrate` as a comment. Then I (or someone else) with committer permissions can sponsor the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2710652078

From stuefe at openjdk.org  Mon Mar 10 14:11:01 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 10 Mar 2025 14:11:01 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v5]
In-Reply-To: <oJjAjXaPQgDh7AYdSDzC3vPbxA669H68ZlbjfyLeDUo=.06dd0b2d-6428-4da4-aa8c-7c0c14d26c9d@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <oJjAjXaPQgDh7AYdSDzC3vPbxA669H68ZlbjfyLeDUo=.06dd0b2d-6428-4da4-aa8c-7c0c14d26c9d@github.com>
Message-ID: <VrSCn0QSbirNrG731vQ1iAldcn_GZKRsV4Nrk-NtifY=.c736b36c-078b-4a2f-9b5e-839d6f901459@github.com>

On Fri, 7 Mar 2025 01:46:37 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

+1

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2671094029

From mbaesken at openjdk.org  Mon Mar 10 15:44:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 10 Mar 2025 15:44:19 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization
 settings
Message-ID: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>

On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

Commit messages:
 - JDK-8351542

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

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

From mbaesken at openjdk.org  Mon Mar 10 15:44:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 10 Mar 2025 15:44:19 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <uNpVp2VwO_3iyoMVRZJVGIgF1iep5lVA0VpUbiw7uIk=.d889dace-b61d-4068-90a6-6d1e9a1af0f0@github.com>

On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

While at it I also cleaned up some unused variable issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2711018344

From duke at openjdk.org  Mon Mar 10 15:49:55 2025
From: duke at openjdk.org (duke)
Date: Mon, 10 Mar 2025 15:49:55 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <0_pyyF2GBxEPskx4gCkuvWEouimdWdMFuigVcpamg7Y=.f89376d9-34f7-43b2-9640-fee0c7b58003@github.com>
Message-ID: <WeHasZlBKvJdQ7MR4Y_CQiTzB7LCmrEvchELsF61MWU=.cc92b7d3-86ff-4f38-bddc-de7b7f62d74e@github.com>

On Sat, 8 Mar 2025 13:39:44 GMT, snake66 <duke at openjdk.org> wrote:

>> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
>> 
>> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
>> 
>> Sponsored by: The FreeBSD Foundation
>> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
>> 
>> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4
>
> snake66 has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Use shell var syntax in libraries.m4
>  - Fix typo PTREAD->PTHREAD
>  - Revert changes to make/Hsdis.gmk

@snake66 
Your change (at version 469997239f26f59cd47df19fb9e836b883687487) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2711042802

From erikj at openjdk.org  Mon Mar 10 17:34:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 17:34:54 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>

On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

make/modules/java.management/Lib.gmk line 33:

> 31: ## Build libmanagement
> 32: ################################################################################
> 33: 

Why remove the comment header. This pattern is used throughout the `make/modules/*/Lib.gmk` files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1987739169

From mbaesken at openjdk.org  Mon Mar 10 18:54:55 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 10 Mar 2025 18:54:55 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings
In-Reply-To: <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
Message-ID: <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>

On Mon, 10 Mar 2025 17:32:07 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> make/modules/java.management/Lib.gmk line 33:
> 
>> 31: ## Build libmanagement
>> 32: ################################################################################
>> 33: 
> 
> Why remove the comment header. This pattern is used throughout the `make/modules/*/Lib.gmk` files.

My motivation was that the comment brings not much value because it just states the obvious. But if you like I can bring back the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1987847982

From amenkov at openjdk.org  Tue Mar 11 01:39:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 11 Mar 2025 01:39:55 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:

  restore ThreadBlockInVM in complete

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23405/files
  - new: https://git.openjdk.org/jdk/pull/23405/files/2a3d4346..ed569cc7

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

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

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

From amenkov at openjdk.org  Tue Mar 11 03:16:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 11 Mar 2025 03:16:57 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
Message-ID: <Cv5gj_nlKbEiEPNQk6K3S4pep8iApUD2JXsTQDl3Qt8=.767a3bac-cb27-4128-827a-0b47e5671ef3@github.com>

On Tue, 11 Mar 2025 01:39:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore ThreadBlockInVM in complete

Added ThreadBlockInVM in complete() method to do the same as old implementation.
It solves macos-aarch64 failure of test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitUncommitRecommit.java test in GHA

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2712455404

From mbaesken at openjdk.org  Tue Mar 11 09:04:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 09:04:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  Bring back comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/e6b748d4..fbe7f56e

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

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

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

From mbaesken at openjdk.org  Tue Mar 11 09:10:03 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 09:10:03 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
 <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>
Message-ID: <a7eQ1CiTpioOaFczPAfZqVMIyi48xDiNIBBqMYWhpPE=.11a7d94b-4ee6-4bc2-8285-957349a385cf@github.com>

On Mon, 10 Mar 2025 18:51:53 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> make/modules/java.management/Lib.gmk line 33:
>> 
>>> 31: ## Build libmanagement
>>> 32: ################################################################################
>>> 33: 
>> 
>> Why remove the comment header. This pattern is used throughout the `make/modules/*/Lib.gmk` files.
>
> My motivation was that the comment brings not much value because it just states the obvious. But if you like I can bring back the comment.

I brought back the comment, maybe it is better to keep it because of consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1988749705

From kevinw at openjdk.org  Tue Mar 11 11:56:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 11:56:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
Message-ID: <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>

On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back comment

src/java.management/share/native/libmanagement/VMManagementImpl.c line 63:

> 61: {
> 62:     jmmOptionalSupport mos;
> 63:     jmm_interface->GetOptionalSupport(env, &mos);

Is it worth making any change here?

We currently ignore the return value from GetOptionalSupport, and no doubt have done for years.
So is the fix to just not record the return value, or should we check it?

Making a change to not capture the return value looks like a statement that it should never be checked.  Even if GetOptionalSupport "can't" really fail with the current implementation, that doesn't seem like the right hint to leave.

Other usage in Java_com_sun_management_internal_DiagnosticCommandImpl_getDiagnosticCommandInfo
also does:
 jint ret = jmm_interface_management_ext->GetOptionalSupport(env, &mos);
 
...and also doesn't check the return value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989081708

From kevinw at openjdk.org  Tue Mar 11 13:24:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 13:24:01 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
Message-ID: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>

On Tue, 11 Mar 2025 09:04:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Bring back comment

make/modules/java.management/Lib.gmk line 35:

> 33: 
> 34: LIBMANAGEMENT_OPTIMIZATION := HIGH
> 35: ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)

On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
..are we saying this is redundant?

It reads like Linux builds with LOW, and this change will change that to HIGH ?

I tested existing build and see -O2 in Linux fastdebug and release builds.  So this ifeq wasn't doing anything?

Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.

We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.

(The same comparison is in make/modules/java.base/lib/CoreLibraries.gmk affecting LIBVERIFY_OPTIMIZATION, but no need to expand this change beyond the management area.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989256782

From mbaesken at openjdk.org  Tue Mar 11 13:39:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 13:39:00 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>
Message-ID: <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com>

On Tue, 11 Mar 2025 11:54:29 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Is it worth making any change here?

This was needed because I removed
DISABLED_WARNINGS_gcc_VMManagementImpl.c
while changing the makefile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989296776

From mbaesken at openjdk.org  Tue Mar 11 13:50:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 13:50:08 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
Message-ID: <rVIvHpWuYSQ3UoY9SeoXxIXGs6rGrbXv1Ml3mBkDaco=.f434dc99-6100-49c3-b389-f7093994b754@github.com>

On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.

The change touches only Linux so Windows stays as it is.

> We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.

I look into this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989318978

From mbaesken at openjdk.org  Tue Mar 11 13:59:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 13:59:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v2]
In-Reply-To: <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <c3fKGNxfAp0jBX_auVhkQdbgm-uUHEt2axXIL5NmGg0=.2146cc85-8fc7-4fda-8104-b137df5b5cbe@github.com>
 <3B8pMV5sb2cg79JQ1D5Elg4q_FpVpjU3ccyA8WJ8mcg=.6379566a-697c-4af9-85e2-8252f01cae3b@github.com>
Message-ID: <jUxe9o-rAaRmC1ezkisP7KeVhFrvHcscySaatF4C-WI=.1620603b-679a-4f0e-a3e8-c9517e92276c@github.com>

On Tue, 11 Mar 2025 13:36:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/java.management/share/native/libmanagement/VMManagementImpl.c line 63:
>> 
>>> 61: {
>>> 62:     jmmOptionalSupport mos;
>>> 63:     jmm_interface->GetOptionalSupport(env, &mos);
>> 
>> Is it worth making any change here?
>> 
>> We currently ignore the return value from GetOptionalSupport, and no doubt have done for years.
>> So is the fix to just not record the return value, or should we check it?
>> 
>> Making a change to not capture the return value looks like a statement that it should never be checked.  Even if GetOptionalSupport "can't" really fail with the current implementation, that doesn't seem like the right hint to leave.
>> 
>> Other usage in Java_com_sun_management_internal_DiagnosticCommandImpl_getDiagnosticCommandInfo
>> also does:
>>  jint ret = jmm_interface_management_ext->GetOptionalSupport(env, &mos);
>>  
>> ...and also doesn't check the return value.
>
>> Is it worth making any change here?
> 
> This was needed because I removed
> DISABLED_WARNINGS_gcc_VMManagementImpl.c
> while changing the makefile.

> Other usage in Java_com_sun_management_internal_DiagnosticCommandImpl_getDiagnosticCommandInfo also does: jint ret = jmm_interface_management_ext->GetOptionalSupport(env, &mos);
> 
> ...and also doesn't check the return value.

Seems this one needs the warning disabling because of the unused variable
DISABLED_WARNINGS_gcc_DiagnosticCommandImpl.c := unused-variable

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1989338573

From mbaesken at openjdk.org  Tue Mar 11 14:14:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 14:14:16 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  Adjust jdk.management/Lib.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/fbe7f56e..2aa878e8

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

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

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

From kevinw at openjdk.org  Tue Mar 11 15:08:05 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 15:08:05 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
Message-ID: <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>

On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jdk.management/Lib.gmk

Hi,  I wasn't saying this is wrong, but that the change should say how it makes things better.  The issues says there are some things most likely not needed.  We should be a bit clearer than that, like:


The removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
Was this always redundant, and does removing it make no change to current build options?
If so, great, let's remove the useless makefile lines.


Remove a compiler directive to avoid unused var warnings, but change the code to make it imply a method has no return value when actually it returns a value: I think you could argue this either way, so I asked if it's really worthwhile.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714681001

From duke at openjdk.org  Tue Mar 11 15:14:04 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 15:14:04 GMT
Subject: Integrated: 8351322: Parameterize link option for pthreads
In-Reply-To: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
Message-ID: <k_Fo07yBcDWjQaVx8M-hu6RaoZ-DE1zHjXo4_PZblzw=.036d0461-a7e9-4b24-9cd3-ceb4da357745@github.com>

On Thu, 6 Mar 2025 10:39:27 GMT, snake66 <duke at openjdk.org> wrote:

> Replace hardcoded instances of `-lpthread` with `$(LIBPTHREAD)`, so that it's possible to parameterize this for platforms that use different flags for enabling posix threads.
> 
> This work is a continuation of the work done by Greg Lewis in [1], but generalized for the full JDK, and set at the configure stage.
> 
> Sponsored by: The FreeBSD Foundation
> Co-authored-by: Greg Lewis <glewis at eyesbeyond.com>
> 
> [1]: https://github.com/battleblow/jdk23u/commit/dbd90aa8ab0b7f5e4865864a7c63d975daacabf4

This pull request has now been integrated.

Changeset: b957e5ed
Author:    Harald Eilertsen <haraldei at anduin.net>
URL:       https://git.openjdk.org/jdk/commit/b957e5ed1a8b77e01aad1bb574e4914131cdbfa6
Stats:     660 lines in 9 files changed: 9 ins; 0 del; 651 mod

8351322: Parameterize link option for pthreads

Reviewed-by: erikj, ihse, dholmes

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

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

From mbaesken at openjdk.org  Tue Mar 11 15:16:54 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 15:16:54 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
Message-ID: <TjVKTFhjwOMtoBJyUlmKbLFrC5J5zOvAlaQZWCEyPXY=.607061ac-ad4d-49bd-aa96-19db8f22edc1@github.com>

On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Remove a compiler directive to avoid unused var warnings, but change the code to make it imply a method has no return value when actually it returns a value: I think you could argue this either way, so I asked if it's really worthwhile.

I can move this into a separate PR, maybe it is indeed much better to separate in because it isn't related to the OPTIMIZATION settings.
Looking at the coding we might  get '-1' back
https://github.com/openjdk/jdk/blob/af9af7e90f7dab5adc7b89b76eb978d269e863de/src/hotspot/share/services/management.cpp#L491
so checking for the return code is probably a good idea (also at the other code location you mentioned).

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714714952

From mbaesken at openjdk.org  Tue Mar 11 15:21:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 11 Mar 2025 15:21:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
Message-ID: <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>

On Tue, 11 Mar 2025 15:04:58 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Was this always redundant, and does removing it make no change to current build options?
> If so, great, let's remove the useless makefile lines.

There was a bit of discussion before in the thread https://mail.openjdk.org/pipermail/build-dev/2025-March/049419.html ' LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug symbols' and the outcome was that removing makes sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714735126

From erikj at openjdk.org  Tue Mar 11 16:02:00 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 16:02:00 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
 <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>
Message-ID: <qtEFUk2gHw4Si5gOrkYU7UzWIMS0lD_FzqjPDVjq6r8=.cb445317-5d97-4f58-ae7b-e7b7c79a97bf@github.com>

On Tue, 11 Mar 2025 15:19:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Was this always redundant, and does removing it make no change to current build options?
> > If so, great, let's remove the useless makefile lines.
> 
> There was a bit of discussion before in the thread https://mail.openjdk.org/pipermail/build-dev/2025-March/049419.html ' LIBMANAGEMENT_OPTIMIZATION special settings on Linux with debug symbols' and the outcome was that removing makes sense.

My conclusion in that thread was that [JDK-7071907](https://bugs.openjdk.org/browse/JDK-7071907) introduced this (for a number of libraries). Before that change, these libraries were built with optimization HIGH, and after, because we (Oracle and I assume most other distributors) always build with debug symbols enabled, the optimization level for these libraries was de facto changed to LOW. This PR would revert that, so it does indeed change how the build behaves. There is at least some historic precedent for changing it this way, even if it was 13 years ago.

I think what Kevin is after is having this explanation made clear in the bug and PR description so that it's made clear what the change is and intends to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2714883676

From kevinw at openjdk.org  Tue Mar 11 18:40:03 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 11 Mar 2025 18:40:03 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
Message-ID: <BAgwiarK__f12_Or-7x_sFNvmfzexOe080Ejr9hitWU=.5b43872e-9a20-4658-b5c1-896af581ee6a@github.com>

On Tue, 11 Mar 2025 14:14:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust jdk.management/Lib.gmk

Yes - this might be a really good change, to move the optimization level up, but we need to be clear what is happening and why, in case it throws up some new issues.

Yes, I would agree with handling the unused variable changes separately.  If somebody finds a problem with the opt level, it can be reverted without other complications.

(and separately, maybe it's worth handling the return value of GetOptionalSupport, which in our implementation really can't be -1 unless you call it  wrongly, but strange things happen and things change 8-) )

I can do some tiers of CI testing to see if any odd issues pop up.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2715367338

From duke at openjdk.org  Tue Mar 11 19:30:22 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 19:30:22 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
Message-ID: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>

Allows for future support for platforms that require different flags for libiconv support.

Sponsored-by: The FreeBSD Foundation

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

Commit messages:
 - 8351323: Parameterize libiconv compiler and linker flags

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

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

From erikj at openjdk.org  Tue Mar 11 19:37:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 19:37:58 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>

On Tue, 11 Mar 2025 19:22:34 GMT, snake66 <duke at openjdk.org> wrote:

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

I think this looks ok, but please wait for Magnus to have a look too.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23995#pullrequestreview-2675894294

From duke at openjdk.org  Tue Mar 11 19:48:58 2025
From: duke at openjdk.org (snake66)
Date: Tue, 11 Mar 2025 19:48:58 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
Message-ID: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>

On Tue, 11 Mar 2025 19:35:45 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> I think this looks ok, but please wait for Magnus to have a look too.

@erikj79 Thanks for the review. I'll wait for Magnus as well, and for the tests to pass :)

One thing I was wondering about is that with this change I think it should be safe to just use `$(ICONV_CFLAGS)` etc when setting the main variable.

I.e. instead of:


      CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
          $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS), \
      CFLAGS_aix := $(ICONV_CFLAGS), \
      CFLAGS_macosx := $(ICONV_CFLAGS), \


We could just do:


      CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
          $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS) \
          $(ICONV_CFLAGS), \


The reason I kept it separate for now is that it used separate assignments for the LDFLAGS variable per platform.

However, it you consider it better to combine it into one platform neutral assignment, I can do that instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2715520647

From mbaesken at openjdk.org  Wed Mar 12 08:24:59 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 08:24:59 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <qtEFUk2gHw4Si5gOrkYU7UzWIMS0lD_FzqjPDVjq6r8=.cb445317-5d97-4f58-ae7b-e7b7c79a97bf@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <T4duM6C47gNZKdpKdaHdIDlDiB4owgfd-3Y66viA7wo=.11462e42-d643-4203-8691-2f7832b41d70@github.com>
 <K8d-g2jhyIZA_7XO2phGWY-kFob0lafYKYPK1Wsl-BQ=.431c80ec-0169-4c07-8e2a-37ff2dad9e8d@github.com>
 <3xbDjufS9tSU9OzOyuzljKdsNei-Wy0cIvNVf4BhGRI=.bccf77b9-721c-4fc9-9f6c-3423a9571329@github.com>
 <qtEFUk2gHw4Si5gOrkYU7UzWIMS0lD_FzqjPDVjq6r8=.cb445317-5d97-4f58-ae7b-e7b7c79a97bf@github.com>
Message-ID: <LBNwFffd5rbsjx3hRGRi7Ku6L7W2W_p8VpKL1vd5ah0=.503177fd-a862-4cc8-9b12-cf9816d4f23c@github.com>

On Tue, 11 Mar 2025 15:59:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think what Kevin is after is having this explanation made clear in the bug and PR description so that it's made clear what the change is and intends to do.

I changed the description in the JBS issue a bit.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2717019564

From ihse at openjdk.org  Wed Mar 12 11:18:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
Message-ID: <fQZaL5F5yG9kT1t-nvC8b3VA_u_k9Duy-vTQeEWLKTU=.678ad67b-f5ad-47ec-9c5a-7ba5355ed9a5@github.com>

On Tue, 11 Mar 2025 13:18:55 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do not handle the unused variables stuff in this change
>
> make/modules/java.management/Lib.gmk line 35:
> 
>> 33: 
>> 34: LIBMANAGEMENT_OPTIMIZATION := HIGH
>> 35: ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
> 
> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
> ..are we saying this is redundant?
> 
> It reads like Linux builds with LOW, and this change will change that to HIGH ?
> 
> I tested existing build and see -O2 in Linux fastdebug and release builds.  So this ifeq wasn't doing anything?
> 
> Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.
> 
> We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.
> 
> (The same comparison is in make/modules/java.base/lib/CoreLibraries.gmk affecting LIBVERIFY_OPTIMIZATION, but no need to expand this change beyond the management area.)

@kevinjwalls 
> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)` ..are we saying this is redundant?
> 
> It reads like Linux builds with LOW, and this change will change that to HIGH ?

No, we are not saying it is redundant. Exactly as you say this PR will change the value from LOW to HIGH. The assumption is that this special case was created more than a decade ago, and no ill effect seems to arise when removing the exception, so it seems to be needed no more. 

This is part of Matthias ongoing effort to simplify and modernize the optimization levels of native libraries in the JDK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991242742

From ihse at openjdk.org  Wed Mar 12 11:18:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>
Message-ID: <uOjWByBEQmtqflpbbXtTYAnTN19Mc_6MVxCwlH3lJh8=.020eadd6-4489-47d5-a67e-bdd5e815c6f4@github.com>

On Wed, 12 Mar 2025 11:15:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not handle the unused variables stuff in this change

src/java.management/share/native/libmanagement/VMManagementImpl.c line 41:

> 39:     jstring version_string = NULL;
> 40: 
> 41:     unsigned int major = ((unsigned int) jmm_version & 0x0FFF0000) >> 16;

Can you please revert this unrelated changes as well?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991245086

From ihse at openjdk.org  Wed Mar 12 11:18:15 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <a7eQ1CiTpioOaFczPAfZqVMIyi48xDiNIBBqMYWhpPE=.11a7d94b-4ee6-4bc2-8285-957349a385cf@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <E2bgW7yD6sU6RoZeirQyM1X0i7WmDhTHFrOlRucXrf0=.136d5fcf-ac47-4338-aa3e-c21d4b594ebc@github.com>
 <4CJJzSDi3wo6PYcpqftuNxA_B9w4fuiL4K3T5E0hczg=.3528a869-1206-4bbc-b656-7abd239e01e4@github.com>
 <a7eQ1CiTpioOaFczPAfZqVMIyi48xDiNIBBqMYWhpPE=.11a7d94b-4ee6-4bc2-8285-957349a385cf@github.com>
Message-ID: <75SREzlDoYwqWP8IeEVKUH6x8ZXagK6nDUkULmBnid0=.eda00d2d-e721-44f9-b890-edad0fe3f5b7@github.com>

On Tue, 11 Mar 2025 09:07:40 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> My motivation was that the comment brings not much value because it just states the obvious. But if you like I can bring back the comment.
>
> I brought back the comment, maybe it is better to keep it because of consistency.

Thank you. I have introduced these headers everywhere to to create consistency and an easy way to search for where native libraries are compiled, so they are definitely useful even if that is not obvious from a single example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991238672

From mbaesken at openjdk.org  Wed Mar 12 11:18:15 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 11:18:15 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  do not handle the unused variables stuff in this change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/2aa878e8..979963a9

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

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

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

From kevinw at openjdk.org  Wed Mar 12 11:24:08 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 12 Mar 2025 11:24:08 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v4]
In-Reply-To: <fQZaL5F5yG9kT1t-nvC8b3VA_u_k9Duy-vTQeEWLKTU=.678ad67b-f5ad-47ec-9c5a-7ba5355ed9a5@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <iyXRHrPS1YUXSy0JFc5Xh2_1P_5LUtFCUlJvt1rtxGg=.06eeb8b1-d8fc-4114-b893-0286c36c5692@github.com>
 <5ANCABiGgAAZPCiSxkKRYq40qANyLt6-8Q_E9kBS6nM=.87201543-63fe-4cb6-9494-081747cee5bc@github.com>
 <fQZaL5F5yG9kT1t-nvC8b3VA_u_k9Duy-vTQeEWLKTU=.678ad67b-f5ad-47ec-9c5a-7ba5355ed9a5@github.com>
Message-ID: <2_A1TGBk_QUchp1EvYXWZpLJ_JZRLGgFvZM5Ia91fjE=.295280a9-0f96-41aa-b8d9-b80ebc092813@github.com>

On Wed, 12 Mar 2025 11:13:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.management/Lib.gmk line 35:
>> 
>>> 33: 
>>> 34: LIBMANAGEMENT_OPTIMIZATION := HIGH
>>> 35: ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
>> 
>> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)`
>> ..are we saying this is redundant?
>> 
>> It reads like Linux builds with LOW, and this change will change that to HIGH ?
>> 
>> I tested existing build and see -O2 in Linux fastdebug and release builds.  So this ifeq wasn't doing anything?
>> 
>> Windows fastdebug and release I just checked and saw -O1, I'm not sure why that is.
>> 
>> We do the same thing in make/modules/jdk.management/Lib.gmk so both these management locations should probably be treated the same.
>> 
>> (The same comparison is in make/modules/java.base/lib/CoreLibraries.gmk affecting LIBVERIFY_OPTIMIZATION, but no need to expand this change beyond the management area.)
>
> @kevinjwalls 
>> On removal of `ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)` ..are we saying this is redundant?
>> 
>> It reads like Linux builds with LOW, and this change will change that to HIGH ?
> 
> No, we are not saying it is redundant. Exactly as you say this PR will change the value from LOW to HIGH. The assumption is that this special case was created more than a decade ago, and no ill effect seems to arise when removing the exception, so it seems to be needed no more. 
> 
> This is part of Matthias ongoing effort to simplify and modernize the optimization levels of native libraries in the JDK.

Thanks yes, I could not reconcile the "most likely not needed" statement with the implied "this will change the opt level", so the intent wasn't clear at first.  I think we're in sync now. 
 Agreed the opt level should be a good change!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991262315

From ihse at openjdk.org  Wed Mar 12 12:14:52 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 12:14:52 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
Message-ID: <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>

On Tue, 11 Mar 2025 19:45:58 GMT, snake66 <duke at openjdk.org> wrote:

> We could just do:
> 
> ```
>       CFLAGS := $(LIBSPLASHSCREEN_CFLAGS) \
>           $(GIFLIB_CFLAGS) $(LIBJPEG_CFLAGS) $(PNG_CFLAGS) $(LIBZ_CFLAGS) \
>           $(ICONV_CFLAGS), \
> ```
> 
> The reason I kept it separate for now is that it used separate assignments for the LDFLAGS variable per platform.
> 
> However, it you consider it better to combine it into one platform neutral assignment, I can do that instead.

This form is much preferred -- if it is possible and correct. That is, if iconv is used on all platforms where it is available.

>From the diff in the PR, it looks like iconv is used exclusively on macOS and AIX. If so, you can change the definition of ICONV_CFLAG etc to be empty on all platforms except on macOS and AIX (and in the upcoming BSD port), and just add the ICONV variables directly as platform neutral. 

But for this to be a good idea, there need to be some sense that this is "futureproof", as in that there will likely never be a need for iconv on Linux, and that there is a reasonable assumption to think that if a JDK library needs iconv it will need it on all "iconv platforms", that is macOS, AIX and BSD. I don't know enough about the specifics of iconv to say this with certainty. Another way to phrase this is perhaps: "why don't we need iconv on linux?"

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717683240

From ihse at openjdk.org  Wed Mar 12 12:17:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 12:17:57 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
 <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
Message-ID: <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>

On Wed, 12 Mar 2025 12:12:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Another way to phrase this is perhaps: "why don't we need iconv on linux?"

I googled this and can answer it myself: because `iconv()` is built into glibc. So then I guess it makes sense to add ICONV variables globally, and define it as empty on linux (and windows), where it is not needed to be specified as a separate library.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717689442

From duke at openjdk.org  Wed Mar 12 12:26:53 2025
From: duke at openjdk.org (snake66)
Date: Wed, 12 Mar 2025 12:26:53 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <qHXUvvjFlMbjs8Pn0RzokBPFYyRZd-YhA_PqJWWeZm8=.9a6d97dd-9e01-44a8-ad66-d8d53ac62268@github.com>
 <-5KNlbfMDAp0wjtJ0dyMbFfcDrpgNPQb-DNJhSot4Y0=.636869ef-5683-42bc-9f6c-81034d619b56@github.com>
 <pdgB0E6C-A8ur3Z0Hvcg5S6ov5hxkxV90Wak63cOgLQ=.7119d64b-a144-420a-b1b3-19ad31e6af79@github.com>
 <MEJI0ODDB8Zy0R8FI9kFSF3N1OnOxLvVuGo5xdgms8s=.9d3ca4b6-378b-415e-b526-bb1bc1e3c56f@github.com>
Message-ID: <GFAItR-gpg2wTrUmZJKQhnQ8nGioIhnMbmVgMOxE5_8=.c4e320d5-86f1-46ce-b5c2-464a5a67cf33@github.com>

On Wed, 12 Mar 2025 12:15:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Another way to phrase this is perhaps: "why don't we need iconv on linux?"
> 
> I googled this and can answer it myself: because `iconv()` is built into glibc. 

Yes, that's what I came to as well. Sorry I didn't include that info in the original description. It seems to be even more complicated on some platforms, where there _is_ built in support for iconv (or a system supplied libiconv), but with limitations so that you may want to prefer the GNU libiconv in any case.

I think we should be able to configure these cases properly also with the proposed changes.

I'll update the PR as outlined in the previous comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2717713872

From mbaesken at openjdk.org  Wed Mar 12 12:45:50 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 12:45:50 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v3]
In-Reply-To: <uOjWByBEQmtqflpbbXtTYAnTN19Mc_6MVxCwlH3lJh8=.020eadd6-4489-47d5-a67e-bdd5e815c6f4@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <F7izoURvgkTLmRlXq2z-G005YR_rOyzWSVXgxEi6bZw=.283a3a99-c3d2-4265-b2fc-7ab5cd257129@github.com>
 <uOjWByBEQmtqflpbbXtTYAnTN19Mc_6MVxCwlH3lJh8=.020eadd6-4489-47d5-a67e-bdd5e815c6f4@github.com>
Message-ID: <7htIj8fq8F1fm1ldEYSZ7qbjGUwmsJoxidI_2inw9FI=.48926cd9-79b4-4674-866d-181a94367c6b@github.com>

On Wed, 12 Mar 2025 11:15:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust jdk.management/Lib.gmk
>
> src/java.management/share/native/libmanagement/VMManagementImpl.c line 41:
> 
>> 39:     jstring version_string = NULL;
>> 40: 
>> 41:     unsigned int major = ((unsigned int) jmm_version & 0x0FFF0000) >> 16;
> 
> Can you please revert this unrelated changes as well?

Sure, this was a mistake I re added the unused line but at the wrong position in the file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23966#discussion_r1991417236

From mbaesken at openjdk.org  Wed Mar 12 12:45:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 12 Mar 2025 12:45:48 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

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

  move code back in VMManagementImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23966/files
  - new: https://git.openjdk.org/jdk/pull/23966/files/979963a9..d82bd2b6

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

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

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

From duke at openjdk.org  Wed Mar 12 13:57:43 2025
From: duke at openjdk.org (snake66)
Date: Wed, 12 Mar 2025 13:57:43 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

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

  Set ICONV_* flags for aix and macosx only

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23995/files
  - new: https://git.openjdk.org/jdk/pull/23995/files/c9382788..d4c4cca5

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

  Stats: 28 lines in 4 files changed: 2 ins; 11 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/23995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23995/head:pull/23995

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

From sgehwolf at openjdk.org  Wed Mar 12 16:45:14 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 12 Mar 2025 16:45:14 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v16]
In-Reply-To: <u5zEdl0x1vOXu2aa3xhsrfg3FZ58oBT08jvalZU9YW0=.2a829b23-b21b-4ec4-b934-816c56d2952a@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
 <u5zEdl0x1vOXu2aa3xhsrfg3FZ58oBT08jvalZU9YW0=.2a829b23-b21b-4ec4-b934-816c56d2952a@github.com>
Message-ID: <qe7LtjqjGRWZpGYMmOFrzhCXMWtgKHbIetUzLm8CdQw=.2a9de207-f568-4357-8346-a6fb7dfc5227@github.com>

On Thu, 20 Feb 2025 14:22:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
>> 
>> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
>> 
>> This patch addresses this issue by:
>> 
>> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
>> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
>> 
>> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
>> 
>> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
>> 
>> Thoughts?
>> 
>> Testing:
>> 
>> - [x] GHA
>> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
>> - [x] Some manual testing using systemd slices
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Fix missing imports
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - Add exclusive access dirs directive for systemd tests
>  - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/e1d0a9c8...74abae5b

Keep open, please.

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

PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2718491360

From ihse at openjdk.org  Wed Mar 12 16:58:55 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 16:58:55 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
Message-ID: <Q9whAUJRCDUNFdG51wTnWdt6DTah2gz4H02IbF-c7nM=.b653c747-7ae8-4e6a-847e-792f44ae38c5@github.com>

On Wed, 12 Mar 2025 13:57:43 GMT, snake66 <duke at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set ICONV_* flags for aix and macosx only

Also, to double check, are the new variables `ICONV_CFLAGS` and `ICONV_LDFLAGS` going to be non-empty on BSD? There is no reason to introduce a variable for completeness sake, if it is never going to have any value. But it is fully okay if they are empty now, but will have a value for BSD.

make/modules/jdk.jdwp.agent/Lib.gmk line 76:

> 74:         java.base:libjava, \
> 75:     JDK_LIBS := java.base:libjvm, \
> 76:     LIBS_linux := $(LIBDL), \

Something got wrong here. You should have kept the LIBS_linux line, and the new LIBS line should be `LIBS := $(ICONV_LIBS)`.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2718530308
PR Review Comment: https://git.openjdk.org/jdk/pull/23995#discussion_r1991917140

From ihse at openjdk.org  Wed Mar 12 17:19:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 12 Mar 2025 17:19:16 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
Message-ID: <Zru6TSjWy97mEt5blgBMctBBvMTc3d8Xbrwf4n1ZhHE=.77dfb0cc-6f01-4d69-b108-26429e7b78a4@github.com>

On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move code back in VMManagementImpl

Marked as reviewed by ihse (Reviewer).

I have run this through our CI system and it looks good!

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

PR Review: https://git.openjdk.org/jdk/pull/23966#pullrequestreview-2679287511
PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2718582751

From cjplummer at openjdk.org  Wed Mar 12 19:05:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Mar 2025 19:05:05 GMT
Subject: RFR: 8351699: Problem list
 com/sun/jdi/JdbStopInNotificationThreadTest.java with ZGC
Message-ID: <xt0lPCcTdqODRIeT5aTpLLpRtMXNxpIfNk3cwg6YTfc=.af90349a-1088-4678-acc0-28d51a19ab4c@github.com>

Put JdbStopInNotificationThreadTest.java on ZGC problem list for all linux platforms. It seems to fail on every linux run with ZGC in our CI.

I'd like to push this as a trivial change.

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

Commit messages:
 - update copyright
 - put JdbStopInNotificationThreadTest.java on ZGC prob

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

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

From amenkov at openjdk.org  Wed Mar 12 19:16:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 12 Mar 2025 19:16:54 GMT
Subject: RFR: 8351699: Problem list
 com/sun/jdi/JdbStopInNotificationThreadTest.java with ZGC
In-Reply-To: <xt0lPCcTdqODRIeT5aTpLLpRtMXNxpIfNk3cwg6YTfc=.af90349a-1088-4678-acc0-28d51a19ab4c@github.com>
References: <xt0lPCcTdqODRIeT5aTpLLpRtMXNxpIfNk3cwg6YTfc=.af90349a-1088-4678-acc0-28d51a19ab4c@github.com>
Message-ID: <ltcPIAhr_vekGuBeCPsR83RJiqkcMmLXM4SUjVdA5L4=.06852d48-0667-4f15-91ea-6aab28713ef2@github.com>

On Wed, 12 Mar 2025 18:46:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Put JdbStopInNotificationThreadTest.java on ZGC problem list for all linux platforms. It seems to fail on every linux run with ZGC in our CI.
> 
> I'd like to push this as a trivial change.

trivial

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

Marked as reviewed by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24017#pullrequestreview-2679622207

From amenkov at openjdk.org  Wed Mar 12 19:32:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 12 Mar 2025 19:32:55 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <GJxbuwM9chjQeU-fbaVvx8iZMRzjm7mu1u9DzbL85-M=.d920d94b-c24d-4561-b758-b8c2bf37ee56@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <5gU2uvop1uCF-ZiCPwrNv0KuCaEms2wpadxOzx5sBqI=.04bca007-b846-44e8-a936-4156cb4e307d@github.com>
 <IEjlHXE81cJ1pFA2Js5uNs-Jis834z1Ve-9m_NPKzF8=.77d96896-4951-452e-9965-9699ad8297b4@github.com>
 <GJxbuwM9chjQeU-fbaVvx8iZMRzjm7mu1u9DzbL85-M=.d920d94b-c24d-4561-b758-b8c2bf37ee56@github.com>
Message-ID: <ZcVsG1FAhaQv5WFdpFx9LqBl0srpJlMQ2Fs-KiJwQQ4=.17990e6d-8676-4308-8332-c8fb63594d31@github.com>

On Mon, 10 Feb 2025 18:25:58 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>>> I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed?
>> 
>> The protocol works as before.
>> All command handlers are updated to set the result code earlier (after argument parsing, but before command execution).
>> After the result code is set, it's sent to the tool and the rest of output (data) are send directly to the tool without buffering.
>
>> > I didn't really understand what makes this streaming. The old protocol first sent out the result, and then the data, has this changed?
>> 
>> The protocol works as before. All command handlers are updated to set the result code earlier (after argument parsing, but before command execution). After the result code is set, it's sent to the tool and the rest of output (data) are send directly to the tool without buffering.
> 
> Aha, I understand. Before, result code meant "Parsing OK, Command Execution OK", now it means "Parsing OK, starting Command Execution". That's fine by me.
> 
> Edit: I'll perform another review round soon!

@jdksjolen , @tstuefe  can you re-review with the last commit please

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2718898375

From cjplummer at openjdk.org  Wed Mar 12 20:43:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Mar 2025 20:43:00 GMT
Subject: RFR: 8351699: Problem list
 com/sun/jdi/JdbStopInNotificationThreadTest.java with ZGC
In-Reply-To: <xt0lPCcTdqODRIeT5aTpLLpRtMXNxpIfNk3cwg6YTfc=.af90349a-1088-4678-acc0-28d51a19ab4c@github.com>
References: <xt0lPCcTdqODRIeT5aTpLLpRtMXNxpIfNk3cwg6YTfc=.af90349a-1088-4678-acc0-28d51a19ab4c@github.com>
Message-ID: <v5njojCsoBeA2cM9Ri-IM5PROBVDTFh7oeXq94yIWs4=.ebd1c339-2fb9-4e58-a678-733cd3be91f5@github.com>

On Wed, 12 Mar 2025 18:46:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Put JdbStopInNotificationThreadTest.java on ZGC problem list for all linux platforms. It seems to fail on every linux run with ZGC in our CI.
> 
> I'd like to push this as a trivial change.

Thank you, Alex!

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

PR Comment: https://git.openjdk.org/jdk/pull/24017#issuecomment-2719073150

From cjplummer at openjdk.org  Wed Mar 12 20:43:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 12 Mar 2025 20:43:00 GMT
Subject: Integrated: 8351699: Problem list
 com/sun/jdi/JdbStopInNotificationThreadTest.java with ZGC
In-Reply-To: <xt0lPCcTdqODRIeT5aTpLLpRtMXNxpIfNk3cwg6YTfc=.af90349a-1088-4678-acc0-28d51a19ab4c@github.com>
References: <xt0lPCcTdqODRIeT5aTpLLpRtMXNxpIfNk3cwg6YTfc=.af90349a-1088-4678-acc0-28d51a19ab4c@github.com>
Message-ID: <WEt_KTErsI-hb6dcrF-BENJh05MzWjls5TYKJ60syOI=.4aadda75-e54f-4f77-a5f1-0f7991e90bda@github.com>

On Wed, 12 Mar 2025 18:46:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Put JdbStopInNotificationThreadTest.java on ZGC problem list for all linux platforms. It seems to fail on every linux run with ZGC in our CI.
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: 5502ce73
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5502ce733e77efa9f40116dd0e34d4d2333a48dc
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8351699: Problem list com/sun/jdi/JdbStopInNotificationThreadTest.java with ZGC

Reviewed-by: amenkov

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

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

From mbaesken at openjdk.org  Thu Mar 13 08:51:05 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Mar 2025 08:51:05 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
Message-ID: <gWcxZ56krbNQuvlUhJNa3UNCblIW202rFQpUzBRciII=.8c2ea5d9-e55c-40b1-9547-42443c10ae1d@github.com>

On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move code back in VMManagementImpl

Thanks for the review and testing in your CI !

Kevin/Erik , are you fine with the change as it is now?

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2720437258

From kevinw at openjdk.org  Thu Mar 13 09:50:12 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Mar 2025 09:50:12 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
Message-ID: <-S_7YK4aaJ5iRuClElccYN_8PMc06Bj5ye5EyWv7CHY=.fe2ff008-ca98-4540-9d99-2b5c463a7cb1@github.com>

On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move code back in VMManagementImpl

Yes looks good.
I'm seeing -O3 in a Linux release build and -O2 in a fastdebug build.

I see the release build libmanagement.so is 48 bytes smaller than before, both around 25k, so no real difference.  Didn't see any new problems in all the management tests.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23966#pullrequestreview-2681208349

From duke at openjdk.org  Thu Mar 13 10:02:59 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 10:02:59 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v2]
In-Reply-To: <Q9whAUJRCDUNFdG51wTnWdt6DTah2gz4H02IbF-c7nM=.b653c747-7ae8-4e6a-847e-792f44ae38c5@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <AL89caeqfi6DRxTvJvfL86Qljn5o3IWgV-jSJocb8aE=.db6a8626-a1e8-4b2d-9e70-06eda24458bc@github.com>
 <Q9whAUJRCDUNFdG51wTnWdt6DTah2gz4H02IbF-c7nM=.b653c747-7ae8-4e6a-847e-792f44ae38c5@github.com>
Message-ID: <ZIzL7K2Zb4GQwvZzIql_t3veZiQQHluz2shWq2MyL1c=.61f01918-d603-4a7d-8c34-bfd5aef7bb19@github.com>

On Wed, 12 Mar 2025 16:56:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Also, to double check, are the new variables `ICONV_CFLAGS` and `ICONV_LDFLAGS` going to be non-empty on BSD? 

Yes, the current BSD port has the following in `libraries.m4`:

  if test "x$OPENJDK_TARGET_OS" = "xbsd"; then
    if test "x$OPENJDK_TARGET_OS_ENV" = "xbsd.openbsd"; then
      ICONV_CFLAGS="-I/usr/local/include"
      ICONV_LDFLAGS="-L/usr/local/lib"
      ICONV_LIBS=-liconv
    elif test "x$OPENJDK_TARGET_OS_ENV" = "xbsd.freebsd"; then
      ICONV_CFLAGS=-DLIBICONV_PLUG
      ICONV_LDFLAGS=
      ICONV_LIBS=
    else
      ICONV_CFLAGS=
      ICONV_LDFLAGS=
      ICONV_LIBS=
    fi
  else
    ICONV_CFLAGS=
    ICONV_LDFLAGS=
    ICONV_LIBS=-liconv
  fi

  AC_SUBST(ICONV_CFLAGS)
  AC_SUBST(ICONV_LDFLAGS)
  AC_SUBST(ICONV_LIBS)


So strictly speaking we only need `ICONV_CFLAGS` for FreeBSD, and `ICONV_LIBS` for aix and macosx. That is if we don't want to include OpenBSD support at this time.

> make/modules/jdk.jdwp.agent/Lib.gmk line 76:
> 
>> 74:         java.base:libjava, \
>> 75:     JDK_LIBS := java.base:libjvm, \
>> 76:     LIBS_linux := $(LIBDL), \
> 
> Something got wrong here. You should have kept the LIBS_linux line, and the new LIBS line should be `LIBS := $(ICONV_LIBS)`.

Ooops, I'll fix!

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2720660907
PR Review Comment: https://git.openjdk.org/jdk/pull/23995#discussion_r1993169985

From duke at openjdk.org  Thu Mar 13 11:39:14 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 11:39:14 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

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

  Unbreak libjdwp build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23995/files
  - new: https://git.openjdk.org/jdk/pull/23995/files/d4c4cca5..a9fdfef5

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

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

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

From mbaesken at openjdk.org  Thu Mar 13 12:45:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Mar 2025 12:45:19 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
Message-ID: <rI0LZFPM6QaEmRAm1ESXqr4KQI1Se-gh_0bE4BdeU3g=.928ce84c-ff0a-49f7-a318-4e3732124e5a@github.com>

On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move code back in VMManagementImpl

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2721123753

From mbaesken at openjdk.org  Thu Mar 13 12:45:19 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Mar 2025 12:45:19 GMT
Subject: Integrated: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings
In-Reply-To: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
Message-ID: <HYmFnPhr0gN8r369gLc1uVIPoVbAEI8eaafOMGY79Nk=.124f72a3-4798-4cc9-9308-fa8be7894037@github.com>

On Mon, 10 Mar 2025 15:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.

This pull request has now been integrated.

Changeset: c3db6671
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3db667156f7e6b7d05c76370973b9f2db9f0d55
Stats:     12 lines in 2 files changed: 0 ins; 10 del; 2 mod

8351542: LIBMANAGEMENT_OPTIMIZATION remove special optimization settings

Reviewed-by: ihse, kevinw

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

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

From ihse at openjdk.org  Thu Mar 13 13:31:59 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 13 Mar 2025 13:31:59 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
Message-ID: <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com>

On Thu, 13 Mar 2025 11:39:14 GMT, snake66 <duke at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unbreak libjdwp build

This looks good to me now.

Then I think the current solution is fine. Even if OpenBSD is not the primary goal of your port, I see no reason to actively work against it either, so if it needs `ICONV_LDFLAGS` then we should include it.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23995#pullrequestreview-2681916914
PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721263178

From weijun at openjdk.org  Thu Mar 13 13:49:17 2025
From: weijun at openjdk.org (Weijun Wang)
Date: Thu, 13 Mar 2025 13:49:17 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <yzZVGiVm3BlSq8WRjOMmm9RzV6xuUa5Nuu8iBJphHtU=.e589a641-10bb-440f-bb08-3f97e7ec5aab@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Actually, you can remove those lines in `security.cpp`. The whole method is for debugging use during my developing work. While the method could still be valuable but those lines are completely useless now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2721318729

From duke at openjdk.org  Thu Mar 13 13:57:10 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 13:57:10 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
 <1pWpryeUL90A8TZ4L8nkpDVfh5bwvDZGf7pNeuAMe-c=.48ae9dd6-056a-431a-8f67-8a0d6ac97abd@github.com>
Message-ID: <m1qZbz8m7JXwV475ZdqpyQjdr09P1ixMXWoBy3jHBkI=.9e6ebf20-7212-41b3-b909-1460982beab9@github.com>

On Thu, 13 Mar 2025 13:28:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> snake66 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Unbreak libjdwp build
>
> Then I think the current solution is fine. Even if OpenBSD is not the primary goal of your port, I see no reason to actively work against it either, so if it needs `ICONV_LDFLAGS` then we should include it.

@magicus @erikj79 Thanks for the reviews and help!

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721341294

From duke at openjdk.org  Thu Mar 13 13:57:12 2025
From: duke at openjdk.org (duke)
Date: Thu, 13 Mar 2025 13:57:12 GMT
Subject: RFR: 8351323: Parameterize compiler and linker flags for iconv
 [v3]
In-Reply-To: <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
 <6-Kgyhc13tqWR3SuBuFJaJBVtEzyvSYmfcI6yc-6cMg=.ab004227-b5b0-4bfb-ae1d-7962d6d0c41c@github.com>
Message-ID: <YYtIQEdikZ7ydFkm6anwQ1-vjxgXcBjuxbWEoapQapo=.bc49eb75-4e82-49bf-bce3-be3c5f7a0a7e@github.com>

On Thu, 13 Mar 2025 11:39:14 GMT, snake66 <duke at openjdk.org> wrote:

>> Allows for future support for platforms that require different flags for libiconv support.
>> 
>> Sponsored-by: The FreeBSD Foundation
>
> snake66 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unbreak libjdwp build

@snake66 
Your change (at version a9fdfef5f18c63deebd64f37825b8b733997c588) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/23995#issuecomment-2721348961

From mbaesken at openjdk.org  Thu Mar 13 16:44:24 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 13 Mar 2025 16:44:24 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
Message-ID: <tgRNe6JdYazYUoeg8YyE5vv03UKTpR7minx6Gzmpt9o=.acb68b8f-81fa-4acf-ab86-93c04e13fc8d@github.com>

On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move code back in VMManagementImpl

As pointed out already, we have a similar special setting here ,  should we also adjust this ?


make/modules/java.base/lib/CoreLibraries.gmk-36-ifeq ($(call isTargetOs, linux)+$(COMPILE_WITH_DEBUG_SYMBOLS), true+true)
make/modules/java.base/lib/CoreLibraries.gmk:37:  LIBVERIFY_OPTIMIZATION := LOW
make/modules/java.base/lib/CoreLibraries.gmk-38-endif
make/modules/java.base/lib/CoreLibraries.gmk-39-
make/modules/java.base/lib/CoreLibraries.gmk-40-$(eval $(call SetupJdkLibrary, BUILD_LIBVERIFY, \
make/modules/java.base/lib/CoreLibraries.gmk-41-    NAME := verify, \
make/modules/java.base/lib/CoreLibraries.gmk:42:    OPTIMIZATION := $(LIBVERIFY_OPTIMIZATION), \
make/modules/java.base/lib/CoreLibraries.gmk-43-    DISABLED_WARNINGS_gcc_check_code.c := unused-variable, \
make/modules/java.base/lib/CoreLibraries.gmk-44-    DISABLED_WARNINGS_clang_check_code.c := unused-variable, \

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2721937986

From jiangli at openjdk.org  Thu Mar 13 16:54:00 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Mar 2025 16:54:00 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK
In-Reply-To: <prYGzfUmCBunysZ8Nb4yiTx0f0ayjgXHBC3Bdbpgw5Q=.8fe9560b-0987-4c41-96e3-7c095046334b@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
 <prYGzfUmCBunysZ8Nb4yiTx0f0ayjgXHBC3Bdbpgw5Q=.8fe9560b-0987-4c41-96e3-7c095046334b@github.com>
Message-ID: <DGt5LBvO9t_-tKyIjm8rviWstR5HGD9Gta39-SQTN40=.209a70b7-f372-46d1-9fda-dc1a655abdf1@github.com>

On Tue, 4 Mar 2025 19:05:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm not familiar with details of the output from the System.map command but the change looks reasonable, hopefully @tstuefe or someone familar with this command and these tests can review.

Thanks, @AlanBateman!

Could anyone help review this change as well? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/23734#issuecomment-2721974341

From duke at openjdk.org  Thu Mar 13 16:58:03 2025
From: duke at openjdk.org (snake66)
Date: Thu, 13 Mar 2025 16:58:03 GMT
Subject: Integrated: 8351323: Parameterize compiler and linker flags for iconv
In-Reply-To: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
References: <rsUYsiq4DUvTDna-9JOvanxTnjV0fs0Aqc80E-2oMIU=.17687640-8377-4cc9-b0fa-a13640bfceb0@github.com>
Message-ID: <vdsWfr8gf1ZwPbul1FP0D2i8GKXAgkm7ejAy-QEvJr0=.249a439e-28ec-4827-80f8-80cefe67d93e@github.com>

On Tue, 11 Mar 2025 19:22:34 GMT, snake66 <duke at openjdk.org> wrote:

> Allows for future support for platforms that require different flags for libiconv support.
> 
> Sponsored-by: The FreeBSD Foundation

This pull request has now been integrated.

Changeset: 771e160d
Author:    Harald Eilertsen <haraldei at anduin.net>
URL:       https://git.openjdk.org/jdk/commit/771e160da4daa98bfe37bf1acba65454c088910c
Stats:     35 lines in 5 files changed: 25 ins; 2 del; 8 mod

8351323: Parameterize compiler and linker flags for iconv

Reviewed-by: ihse, erikj

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

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

From kevinw at openjdk.org  Thu Mar 13 17:44:12 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 13 Mar 2025 17:44:12 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
Message-ID: <Vk3KA4NT87JSq-yTtp2zGqrXvRT0Qk-F8QOsCBBgJlo=.3fa10901-6909-47e1-b0c4-f33f67ab899b@github.com>

On Wed, 12 Mar 2025 12:45:48 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On Linux there are some special settings for LIBMANAGEMENT_OPTIMIZATION that are most likely not needed any more and could be removed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move code back in VMManagementImpl

Yes seems likely the same history for libverify, so should be good to do the same update there.

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2722162206

From lmesnik at openjdk.org  Thu Mar 13 19:06:24 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 13 Mar 2025 19:06:24 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called.
Message-ID: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>

The nsk_jvmti_setFailStatus() sometimes is called after test check results. In these cases the warning logs are generated and hide the real failure reasons. Also, I think it is a error-prone way to set and check error, since check might be just forgotten. Also, the test execution after failure might be incorrect and also make failure analysis harder.
So I think it makes sense to always fail when nsk_jvmti_setFailStatus() is called.

If this is going to work I'll rename it later and add add optional message to be more informative.

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

Commit messages:
 - more fixed tests
 - removed empty lines.
 - set fail status should fails.
 - 8351375: nsk/jvmti/scenarios/events/EM04/em04t001 test should exit with code 97 if fails in unload phase

Changes: https://git.openjdk.org/jdk/pull/24040/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24040&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351375
  Stats: 71 lines in 5 files changed: 47 ins; 19 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24040/head:pull/24040

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

From stuefe at openjdk.org  Thu Mar 13 19:32:55 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 13 Mar 2025 19:32:55 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
Message-ID: <VI4H23m7qkMfZF5cYzD-obuzzEdRftImZpnmceEzb5g=.18d21b4e-8557-40c1-9394-d05c4e0215d6@github.com>

On Tue, 11 Mar 2025 01:39:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore ThreadBlockInVM in complete

Looks still ok

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23405#pullrequestreview-2683165827

From stuefe at openjdk.org  Thu Mar 13 19:39:58 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 13 Mar 2025 19:39:58 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK
In-Reply-To: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
Message-ID: <QgNNCkJS7V0Lp9laWoGq6gJ4BbKhAwx4ZLTtA8koR-o=.a60a249c-16dd-4432-a123-36364c2f6819@github.com>

On Sat, 22 Feb 2025 03:31:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in following tests to not check for shared libraries when running on static JDK:
> 
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java

Small nits, otherwise fine.

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 97:

> 95:             regexBase_committed + "/lib/.*/libjvm.so"
> 96:         };
> 97: 

Nit, misnamed, since its not unconditionally anymore.

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 115:

> 113:             } else {
> 114:                 return StringArrayUtils.concat(shouldMatchUnconditionally_linux,
> 115:                                                shouldMatchUnconditionally_linux_libjvm);

Here, and in DumpTest: please provide a short comment about why we don't want to match libjvm (even if it seems obvious).

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23734#pullrequestreview-2683177865
PR Review Comment: https://git.openjdk.org/jdk/pull/23734#discussion_r1994192659
PR Review Comment: https://git.openjdk.org/jdk/pull/23734#discussion_r1994195194

From amenkov at openjdk.org  Thu Mar 13 20:08:02 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Mar 2025 20:08:02 GMT
Subject: RFR: 8319055: JCMD should not buffer the whole output of commands
 [v6]
In-Reply-To: <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
 <o-Qxdbm0vGmVZHg-IEhl2IdRLHZTztDFux7amfpc6Ak=.f5d8a0e8-7285-4dc2-b104-dff55e2e18cc@github.com>
Message-ID: <eY2hfFxnQOEFfZQDFi6CWqwrEzFNcKvx94zCtY7c2AU=.baa8b750-ce9c-44d2-b8ee-14e8bf17b0a7@github.com>

On Tue, 11 Mar 2025 01:39:55 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> The fix implements streaming output support for attach protocol.
>> See JBS issue for evaluation, summary of the changes in the 1st comment.
>> Testing: tier1..4,hs-tier5-svc
>
> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore ThreadBlockInVM in complete

Thanks for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/23405#issuecomment-2722571807

From amenkov at openjdk.org  Thu Mar 13 20:08:04 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 13 Mar 2025 20:08:04 GMT
Subject: Integrated: 8319055: JCMD should not buffer the whole output of
 commands
In-Reply-To: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
References: <0KUwNVRl8D4U-YFJZU_LDg_3P7Haqq-vPBJKeXz_PRY=.290810f7-5d28-442e-aab6-75a7b866fc89@github.com>
Message-ID: <o5cYlJqEZ9hX-SlNDdOUon8XRdHiRvj_7BfxfWjz-K0=.73f9077e-beaa-469a-9cef-70932ec8115b@github.com>

On Fri, 31 Jan 2025 23:23:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The fix implements streaming output support for attach protocol.
> See JBS issue for evaluation, summary of the changes in the 1st comment.
> Testing: tier1..4,hs-tier5-svc

This pull request has now been integrated.

Changeset: cd1be917
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd1be9175714186b8881a4d08628fdfcc9382bbc
Stats:     603 lines in 12 files changed: 471 ins; 40 del; 92 mod

8319055: JCMD should not buffer the whole output of commands

Reviewed-by: stuefe, jsjolen

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

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

From jiangli at openjdk.org  Thu Mar 13 22:46:54 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Mar 2025 22:46:54 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK [v2]
In-Reply-To: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
Message-ID: <Lft1C2KGULA3szHL42vdO74DZgJ4usCcmoqVNdh0YZ8=.8c9b5a8e-eb86-48e4-b1c1-7c9aa6b0ead9@github.com>

> Please review the fix in following tests to not check for shared libraries when running on static JDK:
> 
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address @tstuefe review:
  - Renamed shouldMatchUnconditionally_<os>_libjvm to shouldMatch_<os>_libjvm in SystemMapTestBase.
  - Added comments to shouldMatchUnconditionally() methods for difference OS cases in SystemMapTestBase.
  - Added comments to DynLibsTest.java.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23734/files
  - new: https://git.openjdk.org/jdk/pull/23734/files/25f2db29..d1975464

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

  Stats: 15 lines in 2 files changed: 9 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/23734.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23734/head:pull/23734

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

From jiangli at openjdk.org  Thu Mar 13 22:46:56 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 13 Mar 2025 22:46:56 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK [v2]
In-Reply-To: <QgNNCkJS7V0Lp9laWoGq6gJ4BbKhAwx4ZLTtA8koR-o=.a60a249c-16dd-4432-a123-36364c2f6819@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
 <QgNNCkJS7V0Lp9laWoGq6gJ4BbKhAwx4ZLTtA8koR-o=.a60a249c-16dd-4432-a123-36364c2f6819@github.com>
Message-ID: <kcWUmQNj-qqc568-0qsASTCXc2amYq9kooB-9RaQSeM=.ab3c9c6c-fd09-4e14-b281-cf273bafd48b@github.com>

On Thu, 13 Mar 2025 19:35:27 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @tstuefe review:
>>   - Renamed shouldMatchUnconditionally_<os>_libjvm to shouldMatch_<os>_libjvm in SystemMapTestBase.
>>   - Added comments to shouldMatchUnconditionally() methods for difference OS cases in SystemMapTestBase.
>>   - Added comments to DynLibsTest.java.
>
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 97:
> 
>> 95:             regexBase_committed + "/lib/.*/libjvm.so"
>> 96:         };
>> 97: 
> 
> Nit, misnamed, since its not unconditionally anymore.

Done. Also renamed for other OSs.

> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java line 115:
> 
>> 113:             } else {
>> 114:                 return StringArrayUtils.concat(shouldMatchUnconditionally_linux,
>> 115:                                                shouldMatchUnconditionally_linux_libjvm);
> 
> Here, and in DumpTest: please provide a short comment about why we don't want to match libjvm (even if it seems obvious).

Add comments. Please let me know if that covers all cases in your suggestion.

@tstuefe Could you please approve again after the updates? Thanks for the review!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23734#discussion_r1994389318
PR Review Comment: https://git.openjdk.org/jdk/pull/23734#discussion_r1994390355

From stuefe at openjdk.org  Fri Mar 14 06:18:03 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 14 Mar 2025 06:18:03 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK [v2]
In-Reply-To: <Lft1C2KGULA3szHL42vdO74DZgJ4usCcmoqVNdh0YZ8=.8c9b5a8e-eb86-48e4-b1c1-7c9aa6b0ead9@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
 <Lft1C2KGULA3szHL42vdO74DZgJ4usCcmoqVNdh0YZ8=.8c9b5a8e-eb86-48e4-b1c1-7c9aa6b0ead9@github.com>
Message-ID: <DEM5yzICgQqgrbNv4CHeLGHVDWod5y0Gwl4Di8td-Eg=.03d9f99b-e9a1-418f-8501-7ffa6d379e51@github.com>

On Thu, 13 Mar 2025 22:46:54 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review the fix in following tests to not check for shared libraries when running on static JDK:
>> 
>> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
>> test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
>> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address @tstuefe review:
>   - Renamed shouldMatchUnconditionally_<os>_libjvm to shouldMatch_<os>_libjvm in SystemMapTestBase.
>   - Added comments to shouldMatchUnconditionally() methods for difference OS cases in SystemMapTestBase.
>   - Added comments to DynLibsTest.java.

Good, thanks for addressing the nits

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23734#pullrequestreview-2684430340

From mbaesken at openjdk.org  Fri Mar 14 08:34:00 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Mar 2025 08:34:00 GMT
Subject: RFR: 8351542: LIBMANAGEMENT_OPTIMIZATION remove special
 optimization settings [v5]
In-Reply-To: <Vk3KA4NT87JSq-yTtp2zGqrXvRT0Qk-F8QOsCBBgJlo=.3fa10901-6909-47e1-b0c4-f33f67ab899b@github.com>
References: <mu4wIOvZcMMId8LetaMuDubep6JpIdq72CNyeHybxfw=.90d9bba4-b2b7-4751-a94d-28e8462fb84e@github.com>
 <wE0XXf1BgqOyU07usJNFDlW8ekQGltkqn5puyTVdedk=.7107036d-4d70-487f-9649-9375ac04af4f@github.com>
 <Vk3KA4NT87JSq-yTtp2zGqrXvRT0Qk-F8QOsCBBgJlo=.3fa10901-6909-47e1-b0c4-f33f67ab899b@github.com>
Message-ID: <hJ6oQtb7wC4jmXbo352QSGFflNpmCWwHfWOFIi9bpfI=.9dcd9ab2-6118-4cb4-89b5-015da4a98835@github.com>

On Thu, 13 Mar 2025 17:41:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Yes seems likely the same history for libverify, so should be good to do the same update there.

I created https://bugs.openjdk.org/browse/JDK-8352015 .

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

PR Comment: https://git.openjdk.org/jdk/pull/23966#issuecomment-2723988627

From mbaesken at openjdk.org  Fri Mar 14 10:11:41 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Mar 2025 10:11:41 GMT
Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings
Message-ID: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>

We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided.
This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) ,

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

Commit messages:
 - JDK-8351821

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

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

From mbaesken at openjdk.org  Fri Mar 14 10:58:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 14 Mar 2025 10:58:52 GMT
Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings
In-Reply-To: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
References: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
Message-ID: <bwOPAeEfSka4uwVtLognf6Un46sumAITDyq-sa2EzK0=.c1486dcf-3ff4-40dc-abda-3c46f588b4a9@github.com>

On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided.
> This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) ,

In case someone has a good/better idea what to do with the ignored returned value of
`jmm_interface->GetOptionalSupport(....)`
(throwing an exception?  printing out something?)
we can do this of course too.

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

PR Comment: https://git.openjdk.org/jdk/pull/24052#issuecomment-2724321246

From ihse at openjdk.org  Fri Mar 14 11:38:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 14 Mar 2025 11:38:03 GMT
Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings
In-Reply-To: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
References: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
Message-ID: <1XhEwT6egNq_EkiR6p2wq1qGkDXOLa-A4jt_EH_ZHUo=.4a490d5b-7f3f-48d2-b8ab-5bc335c37f7d@github.com>

On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided.
> This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) ,

Build changes look good to me.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24052#pullrequestreview-2685242504

From jiangli at openjdk.org  Fri Mar 14 16:28:07 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Mar 2025 16:28:07 GMT
Subject: RFR: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK [v2]
In-Reply-To: <DEM5yzICgQqgrbNv4CHeLGHVDWod5y0Gwl4Di8td-Eg=.03d9f99b-e9a1-418f-8501-7ffa6d379e51@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
 <Lft1C2KGULA3szHL42vdO74DZgJ4usCcmoqVNdh0YZ8=.8c9b5a8e-eb86-48e4-b1c1-7c9aa6b0ead9@github.com>
 <DEM5yzICgQqgrbNv4CHeLGHVDWod5y0Gwl4Di8td-Eg=.03d9f99b-e9a1-418f-8501-7ffa6d379e51@github.com>
Message-ID: <OvNwZeXxS2z_w9yozj0j2K6_Eb8OwT2_KcWHJiZXJYQ=.6d80fee0-68ee-4c26-9b3e-391b3e96bbed@github.com>

On Fri, 14 Mar 2025 06:15:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address @tstuefe review:
>>   - Renamed shouldMatchUnconditionally_<os>_libjvm to shouldMatch_<os>_libjvm in SystemMapTestBase.
>>   - Added comments to shouldMatchUnconditionally() methods for difference OS cases in SystemMapTestBase.
>>   - Added comments to DynLibsTest.java.
>
> Good, thanks for addressing the nits

Thanks, @tstuefe!

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

PR Comment: https://git.openjdk.org/jdk/pull/23734#issuecomment-2725174357

From jiangli at openjdk.org  Fri Mar 14 16:28:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 14 Mar 2025 16:28:08 GMT
Subject: Integrated: 8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1
 tests fail on static JDK
In-Reply-To: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
References: <h0Tdhsefk9r93sF-esx8WDOG_6qahugvbM2IHzJZGZo=.16c7722c-4677-44f5-aa52-4399162d9488@github.com>
Message-ID: <bwl82D5RseO5clSvXOTEo-VMG8GvJQuS-KLWsdyb9cs=.544868c3-7da4-476f-bd9f-4675b1aab50c@github.com>

On Sat, 22 Feb 2025 03:31:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review the fix in following tests to not check for shared libraries when running on static JDK:
> 
> test/hotspot/jtreg/serviceability/dcmd/vm/DynLibsTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
> test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java

This pull request has now been integrated.

Changeset: 7f428041
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f42804148fca3fb6ff669c35c4086c9fafc7ad3
Stats:     76 lines in 4 files changed: 55 ins; 4 del; 17 mod

8350524: Some hotspot/jtreg/serviceability/dcmd/vm tier1 tests fail on static JDK

Reviewed-by: stuefe

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

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

From kevinw at openjdk.org  Fri Mar 14 20:58:51 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 14 Mar 2025 20:58:51 GMT
Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings
In-Reply-To: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
References: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
Message-ID: <xatp834ELTf4j3kGfbc4cJhm-r95kEEYgR9gK2UX554=.12fea500-267d-4808-80c3-5ed468b22efb@github.com>

On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided.
> This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) ,

We know GetOptionalSupport can't realistically fail, unless we call it with a bad pointer (we don't).
This location is called once only on startup.
We have not checked the return value since introduced in jdk5...  So can't really object to not saving that value in a temp that we ignore, and simplifying the Makefile a little!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24052#pullrequestreview-2686805647

From mbaesken at openjdk.org  Sun Mar 16 13:07:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sun, 16 Mar 2025 13:07:56 GMT
Subject: RFR: 8351821: VMManagementImpl.c avoid switching off warnings
In-Reply-To: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
References: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
Message-ID: <a6ClGd_5ZymFqUvdf-zQ_5aB58R1g_A2Ok2eCo22EjI=.b2939edf-405b-44c5-b217-576d215c2fb2@github.com>

On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided.
> This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) ,

Thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/24052#issuecomment-2727387281

From mbaesken at openjdk.org  Sun Mar 16 13:07:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Sun, 16 Mar 2025 13:07:56 GMT
Subject: Integrated: 8351821: VMManagementImpl.c avoid switching off warnings
In-Reply-To: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
References: <qdoSCW1c23VtX1NzeOYh7oHBH39KAptyJWBrJZ1zVZA=.4d6ef2f4-e65c-4746-8966-568c47ab3f8f@github.com>
Message-ID: <GeKUVM4p8pg2QHmx8HX4_rUI-Q2eca8JDKGPNroS6rM=.e28f9df6-3667-42ba-b3e4-65768c666cbd@github.com>

On Fri, 14 Mar 2025 10:06:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We switched off unused-variable warnings for the file VMManagementImpl.c, this should be avoided.
> This came up in [JDK-8351542](https://bugs.openjdk.org/browse/JDK-8351542) ,

This pull request has now been integrated.

Changeset: 06289f3d
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/06289f3d90577d220de5509a3892f7ed260c24b9
Stats:     8 lines in 2 files changed: 0 ins; 6 del; 2 mod

8351821: VMManagementImpl.c avoid switching off warnings

Reviewed-by: ihse, kevinw

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

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

From dholmes at openjdk.org  Mon Mar 17 06:43:58 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 17 Mar 2025 06:43:58 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
Message-ID: <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>

On Fri, 7 Mar 2025 00:18:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> What is the intended way of using this? Do you run make with LIBPTHREAD=-pthread or do you apply a patch on libraries.m4 for the specific way of linking to pthread?
>> 
>> This is in preparation of the upcoming BSD port, which uses `-pthread` instead of `-pthread`. It was me who suggested that this is done separately with the existing code, to minimize the patch of the BSD port.
>
> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??

> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?

Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.

> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.

I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2728361931

From duke at openjdk.org  Mon Mar 17 10:47:06 2025
From: duke at openjdk.org (snake66)
Date: Mon, 17 Mar 2025 10:47:06 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
Message-ID: <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com>

On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??
>
>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
> 
>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.
> 
> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

> > Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> (...) I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.

I'm happy to test this, if you want. Won't have time this week, though.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2729033496

From jiangli at openjdk.org  Mon Mar 17 19:43:04 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 17 Mar 2025 19:43:04 GMT
Subject: RFR: 8352098: -Xrunjdwp fails on static JDK
Message-ID: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>

Please review this fix that avoids `JvmtiAgent::convert_xrun_agent` from prematurely exiting VM if `lookup_On_Load_entry_point` cannot load the agent using `JVM_OnLoad` symbol. Thanks

`lookup_On_Load_entry_point` first tries to load the builtin agent from the executable by checking the requested symbol (`JVM_OnLoad`). If no builtin agent is found, it then tries to load the agent shared library (e.g. `libjdwp.so`) by calling `load_library`. The issue is that `load_library` is called with `vm_exit_on_error` set to `true`, which causes the VM to exit immediately if the agent shared library is not loaded. Therefore, `JvmtiAgent::convert_xrun_agent` has no chance to try loading the agent using `Agent_OnLoad` symbol (https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/prims/jvmtiAgent.cpp#L352). This is a hidden issue on regular JDK, since the `load_library` can successfully find the agent shared library when `JvmtiAgent::convert_xrun_agent` first tries to load the agent using `JVM_OnLoad` symbol. The issue is noticed on static JDK as there is no `libjdwp.so` in static JDK. It can be reproduced with jtreg `runtime/6294277/Sourc
 eDebugExtension.java` test.

As part of the fix, I cleaned up following in `invoke_JVM_OnLoad` and `invoke_Agent_OnLoad`. If there's an error, the VM should already have exited during `lookup_<JVM|Agent>_OnLoad_entry_point` in those cases.


  if (on_load_entry == nullptr) {
    vm_exit_during_initialization("Could not find ... function in -Xrun library", agent->name());
  }

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

Commit messages:
 - Add 'assert(on_load_entry != nullptr, "invariant");'
 - Cleanup
 - Return nullptr if lookup_On_Load_entry_point does not load agent from executable or library.
 - When called from JvmtiAgent::convert_xrun_agent, don't report any error and bail out too early in lookup_JVM_OnLoad_entry_point if it does not succeed, since we want to try lookup_Agent_OnLoad_entry_point for Agent_OnLoad as well.

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

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

From amenkov at openjdk.org  Mon Mar 17 20:43:16 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 17 Mar 2025 20:43:16 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
Message-ID: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>

The change fixes crash on AIX after JDK-8319055
Can't test it on AIX, but the reason is obvious from the stack trace.
AIX is the only platform that does not implement `reply_writer` yet

Testing: sanity tier1

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

Commit messages:
 - fix

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

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

From dholmes at openjdk.org  Tue Mar 18 02:04:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 02:04:12 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
Message-ID: <Es-9rYh9ZNbqOO_iN_cTr_2Jq1P5Yt5qDoURThhJ5Hc=.91bc3158-4f90-4133-a550-edcc0d54968e@github.com>

On Mon, 17 Mar 2025 20:35:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes crash on AIX after JDK-8319055
> Can't test it on AIX, but the reason is obvious from the stack trace.
> AIX is the only platform that does not implement `reply_writer` yet
> 
> Testing: sanity tier1

This is obviously a necessary fix (per the comment on `complete`.) and so I'm hitting approve. But I'm not sure this is sufficient.

src/hotspot/share/services/attachListener.cpp line 130:

> 128:   // If reply_writer is provided, writes the results.
> 129:   void complete() {
> 130:     if (_reply_writer != nullptr) {

Is this sufficient? I'm looking at JDK-8319055 for the first time and I can't figure out how the value of `_reply_writer` affects the `_allow_streaming` logic that accesses the reply-writer. We seem to enable streaming mode in platform independent code, yet the availability of the reply-writer is platform dependent! ???

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24089#pullrequestreview-2692593449
PR Review Comment: https://git.openjdk.org/jdk/pull/24089#discussion_r1999992737

From dholmes at openjdk.org  Tue Mar 18 02:08:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 02:08:19 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <Es-9rYh9ZNbqOO_iN_cTr_2Jq1P5Yt5qDoURThhJ5Hc=.91bc3158-4f90-4133-a550-edcc0d54968e@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <Es-9rYh9ZNbqOO_iN_cTr_2Jq1P5Yt5qDoURThhJ5Hc=.91bc3158-4f90-4133-a550-edcc0d54968e@github.com>
Message-ID: <hKipfeFCMwh8QgdYAkpV_jTNVB1UqhN1Te8OFDGx-uY=.064bec94-4cd6-4037-ac48-9872bc835f1c@github.com>

On Tue, 18 Mar 2025 02:00:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The change fixes crash on AIX after JDK-8319055
>> Can't test it on AIX, but the reason is obvious from the stack trace.
>> AIX is the only platform that does not implement `reply_writer` yet
>> 
>> Testing: sanity tier1
>
> src/hotspot/share/services/attachListener.cpp line 130:
> 
>> 128:   // If reply_writer is provided, writes the results.
>> 129:   void complete() {
>> 130:     if (_reply_writer != nullptr) {
> 
> Is this sufficient? I'm looking at JDK-8319055 for the first time and I can't figure out how the value of `_reply_writer` affects the `_allow_streaming` logic that accesses the reply-writer. We seem to enable streaming mode in platform independent code, yet the availability of the reply-writer is platform dependent! ???

Ah found it - sorry:

_allow_streaming(reply_writer == nullptr ? false : allow_streaming),

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24089#discussion_r1999997622

From dholmes at openjdk.org  Tue Mar 18 02:52:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 02:52:11 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
Message-ID: <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>

On Tue, 18 Mar 2025 00:16:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes regression from JDK-8319055 (see David's evaluation in the CR description)
> 
> Testing: sanity tier1;
>   tier6, tier7 - in progress

Fix looks good.

Any idea on why things are taking so long? Is the pipe undersized?

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24091#pullrequestreview-2692723214

From dholmes at openjdk.org  Tue Mar 18 04:01:21 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 18 Mar 2025 04:01:21 GMT
Subject: RFR: 8352098: -Xrunjdwp fails on static JDK
In-Reply-To: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
References: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
Message-ID: <1t0ksTv8cjRsnQ756fJahmEOVBDWfenL0m05RE3iUN0=.3222c934-ba11-4931-8393-a42925d082d4@github.com>

On Mon, 17 Mar 2025 19:37:48 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this fix that avoids `JvmtiAgent::convert_xrun_agent` from prematurely exiting VM if `lookup_On_Load_entry_point` cannot load the agent using `JVM_OnLoad` symbol. Thanks
> 
> `lookup_On_Load_entry_point` first tries to load the builtin agent from the executable by checking the requested symbol (`JVM_OnLoad`). If no builtin agent is found, it then tries to load the agent shared library (e.g. `libjdwp.so`) by calling `load_library`. The issue is that `load_library` is called with `vm_exit_on_error` set to `true`, which causes the VM to exit immediately if the agent shared library is not loaded. Therefore, `JvmtiAgent::convert_xrun_agent` has no chance to try loading the agent using `Agent_OnLoad` symbol (https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/prims/jvmtiAgent.cpp#L352). This is a hidden issue on regular JDK, since the `load_library` can successfully find the agent shared library when `JvmtiAgent::convert_xrun_agent` first tries to load the agent using `JVM_OnLoad` symbol. The issue is noticed on static JDK as there is no `libjdwp.so` in static JDK. It can be reproduced with jtreg `runtime/6294277/Sou
 rceDebugExtension.java` test.
> 
> As part of the fix, I cleaned up following in `invoke_JVM_OnLoad` and `invoke_Agent_OnLoad`. If there's an error, the VM should already have exited during `lookup_<JVM|Agent>_OnLoad_entry_point` in those cases.
> 
> 
>   if (on_load_entry == nullptr) {
>     vm_exit_during_initialization("Could not find ... function in -Xrun library", agent->name());
>   }

This seems reasonable to me. A couple of nits.

Thanks

src/hotspot/share/prims/jvmtiAgent.cpp line 360:

> 358:   // to try lookup_Agent_OnLoad_entry_point for Agent_OnLoad as well.
> 359:   OnLoadEntry_t on_load_entry = lookup_JVM_OnLoad_entry_point(
> 360:     this, /* vm exit on error */ false);

Suggestion:

  OnLoadEntry_t on_load_entry = lookup_JVM_OnLoad_entry_point(this, /* vm exit on error */ false);

src/hotspot/share/prims/jvmtiAgent.cpp line 365:

> 363:   if (on_load_entry == nullptr) {
> 364:     on_load_entry = lookup_Agent_OnLoad_entry_point(
> 365:       this, /* vm exit on error */ true);

Suggestion:

    on_load_entry = lookup_Agent_OnLoad_entry_point(this, /* vm exit on error */ true);

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24086#pullrequestreview-2692846277
PR Review Comment: https://git.openjdk.org/jdk/pull/24086#discussion_r2000148624
PR Review Comment: https://git.openjdk.org/jdk/pull/24086#discussion_r2000148978

From alanb at openjdk.org  Tue Mar 18 07:44:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Mar 2025 07:44:09 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
Message-ID: <Imjzg82Tl3Y2iVCniAbvpUE2YsVG1l33W4bGgXMt6Ew=.e675596e-ad87-495c-8237-e08756982676@github.com>

On Tue, 18 Mar 2025 00:16:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes regression from JDK-8319055 (see David's evaluation in the CR description)
> 
> Testing: sanity tier1;
>   tier6, tier7 - in progress

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24091#pullrequestreview-2693319363

From alanb at openjdk.org  Tue Mar 18 07:44:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 18 Mar 2025 07:44:10 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
 <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>
Message-ID: <UvUBCvW0o8r0s2bHJc_Si26P33GGKQjP70cYrITL_18=.c90c355f-f1da-4353-af85-90e40b553c41@github.com>

On Tue, 18 Mar 2025 02:49:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Any idea on why things are taking so long? Is the pipe undersized?

It's usually just handled by Windows although I think you can override/configure with SetNamedPipeHandleState.

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

PR Comment: https://git.openjdk.org/jdk/pull/24091#issuecomment-2731972419

From mdoerr at openjdk.org  Tue Mar 18 09:24:12 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Mar 2025 09:24:12 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
Message-ID: <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>

On Mon, 17 Mar 2025 20:35:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes crash on AIX after JDK-8319055
> Can't test it on AIX, but the reason is obvious from the stack trace.
> AIX is the only platform that does not implement `reply_writer` yet
> 
> Testing: sanity tier1

LGTM. Thanks for fixing it so quickly! Should `reply_writer` get implemented? We could file an RFE.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24089#pullrequestreview-2693629227

From jiangli at openjdk.org  Tue Mar 18 16:54:51 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Mar 2025 16:54:51 GMT
Subject: RFR: 8352098: -Xrunjdwp fails on static JDK [v2]
In-Reply-To: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
References: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
Message-ID: <Cwaj85vMP7yUW93kVr5G1Np9r70HXeqruZITD3JPKkU=.90b4dded-04c6-4357-9b27-4680a8f99ce0@github.com>

> Please review this fix that avoids `JvmtiAgent::convert_xrun_agent` from prematurely exiting VM if `lookup_On_Load_entry_point` cannot load the agent using `JVM_OnLoad` symbol. Thanks
> 
> `lookup_On_Load_entry_point` first tries to load the builtin agent from the executable by checking the requested symbol (`JVM_OnLoad`). If no builtin agent is found, it then tries to load the agent shared library (e.g. `libjdwp.so`) by calling `load_library`. The issue is that `load_library` is called with `vm_exit_on_error` set to `true`, which causes the VM to exit immediately if the agent shared library is not loaded. Therefore, `JvmtiAgent::convert_xrun_agent` has no chance to try loading the agent using `Agent_OnLoad` symbol (https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/prims/jvmtiAgent.cpp#L352). This is a hidden issue on regular JDK, since the `load_library` can successfully find the agent shared library when `JvmtiAgent::convert_xrun_agent` first tries to load the agent using `JVM_OnLoad` symbol. The issue is noticed on static JDK as there is no `libjdwp.so` in static JDK. It can be reproduced with jtreg `runtime/6294277/Sou
 rceDebugExtension.java` test.
> 
> As part of the fix, I cleaned up following in `invoke_JVM_OnLoad` and `invoke_Agent_OnLoad`. If there's an error, the VM should already have exited during `lookup_<JVM|Agent>_OnLoad_entry_point` in those cases.
> 
> 
>   if (on_load_entry == nullptr) {
>     vm_exit_during_initialization("Could not find ... function in -Xrun library", agent->name());
>   }

Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:

 - Apply @dholmes-ora's edit suggestion.
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Apply @dholmes-ora's suggestion to use single line.
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24086/files
  - new: https://git.openjdk.org/jdk/pull/24086/files/b165b86f..745d4c0e

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

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

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

From jiangli at openjdk.org  Tue Mar 18 16:59:08 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Mar 2025 16:59:08 GMT
Subject: RFR: 8352098: -Xrunjdwp fails on static JDK [v2]
In-Reply-To: <1t0ksTv8cjRsnQ756fJahmEOVBDWfenL0m05RE3iUN0=.3222c934-ba11-4931-8393-a42925d082d4@github.com>
References: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
 <1t0ksTv8cjRsnQ756fJahmEOVBDWfenL0m05RE3iUN0=.3222c934-ba11-4931-8393-a42925d082d4@github.com>
Message-ID: <iKKtju9uk-UwV2TPHlQLknw4WmLTuLjZ3juzacvn-4I=.1003dfcd-27b8-45bb-96f3-83e6bed579f0@github.com>

On Tue, 18 Mar 2025 03:58:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems reasonable to me. A couple of nits.
> 
> Thanks

Thanks for the quick review, @dholmes-ora!

Could anyone also help review as a second reviewer? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/24086#issuecomment-2734020892

From cjplummer at openjdk.org  Tue Mar 18 17:46:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 18 Mar 2025 17:46:09 GMT
Subject: RFR: 8352098: -Xrunjdwp fails on static JDK [v2]
In-Reply-To: <Cwaj85vMP7yUW93kVr5G1Np9r70HXeqruZITD3JPKkU=.90b4dded-04c6-4357-9b27-4680a8f99ce0@github.com>
References: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
 <Cwaj85vMP7yUW93kVr5G1Np9r70HXeqruZITD3JPKkU=.90b4dded-04c6-4357-9b27-4680a8f99ce0@github.com>
Message-ID: <BTgh3KcLu1UcaxABDb9FPc2advPQ69YI9TJmIEAb4LQ=.233707ea-fade-4d9f-863d-9a9640aad327@github.com>

On Tue, 18 Mar 2025 16:54:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Please review this fix that avoids `JvmtiAgent::convert_xrun_agent` from prematurely exiting VM if `lookup_On_Load_entry_point` cannot load the agent using `JVM_OnLoad` symbol. Thanks
>> 
>> `lookup_On_Load_entry_point` first tries to load the builtin agent from the executable by checking the requested symbol (`JVM_OnLoad`). If no builtin agent is found, it then tries to load the agent shared library (e.g. `libjdwp.so`) by calling `load_library`. The issue is that `load_library` is called with `vm_exit_on_error` set to `true`, which causes the VM to exit immediately if the agent shared library is not loaded. Therefore, `JvmtiAgent::convert_xrun_agent` has no chance to try loading the agent using `Agent_OnLoad` symbol (https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/prims/jvmtiAgent.cpp#L352). This is a hidden issue on regular JDK, since the `load_library` can successfully find the agent shared library when `JvmtiAgent::convert_xrun_agent` first tries to load the agent using `JVM_OnLoad` symbol. The issue is noticed on static JDK as there is no `libjdwp.so` in static JDK. It can be reproduced with jtreg `runtime/6294277/So
 urceDebugExtension.java` test.
>> 
>> As part of the fix, I cleaned up following in `invoke_JVM_OnLoad` and `invoke_Agent_OnLoad`. If there's an error, the VM should already have exited during `lookup_<JVM|Agent>_OnLoad_entry_point` in those cases.
>> 
>> 
>>   if (on_load_entry == nullptr) {
>>     vm_exit_during_initialization("Could not find ... function in -Xrun library", agent->name());
>>   }
>
> Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Apply @dholmes-ora's edit suggestion.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Apply @dholmes-ora's suggestion to use single line.
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

I had a look yesterday and it looked good, and your latest changes look good also.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24086#pullrequestreview-2695605225

From amenkov at openjdk.org  Tue Mar 18 17:57:14 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 17:57:14 GMT
Subject: RFR: 8352180: AttachListenerThread causes many tests to timeout on
 Windows
In-Reply-To: <UvUBCvW0o8r0s2bHJc_Si26P33GGKQjP70cYrITL_18=.c90c355f-f1da-4353-af85-90e40b553c41@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
 <DXm4w2it939kzDfA5g4fmOK4WA41OTx8NGB8Mdn4QF0=.01f4affa-d23a-4780-97a4-22b6da240bfd@github.com>
 <UvUBCvW0o8r0s2bHJc_Si26P33GGKQjP70cYrITL_18=.c90c355f-f1da-4353-af85-90e40b553c41@github.com>
Message-ID: <FemDN4NorXIndhSaKNjC9bakMegrYAv0oV-IjC6DMjE=.a5352840-9806-4ccf-90e5-e49c35780839@github.com>

On Tue, 18 Mar 2025 07:40:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Any idea on why things are taking so long? Is the pipe undersized?

I don't think this in a buffer issue.
One problem I see is self-attach. FlushFileBuffers waits until all data is read by the client, but is we are at safepoint, the client cannot read the data

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

PR Comment: https://git.openjdk.org/jdk/pull/24091#issuecomment-2734221965

From amenkov at openjdk.org  Tue Mar 18 17:57:15 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 17:57:15 GMT
Subject: Integrated: 8352180: AttachListenerThread causes many tests to timeout
 on Windows
In-Reply-To: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
References: <2m17tGHOtd9pf166GC5_VJYwJ1YwqQ438w5JLLkbNL0=.b8adb288-03ee-44f1-b93d-9e254729a011@github.com>
Message-ID: <_b3Qh7NZHKhwUtBtO_MAsMEh4JAkrWPHRaeVtmVsS0Q=.2b65d38f-628b-4fc0-8574-93cd955b1b90@github.com>

On Tue, 18 Mar 2025 00:16:40 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes regression from JDK-8319055 (see David's evaluation in the CR description)
> 
> Testing: sanity tier1;
>   tier6, tier7 - in progress

This pull request has now been integrated.

Changeset: 53c5b93c
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/53c5b93ca528ec21628c2b03dd6064e02f7ac408
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8352180: AttachListenerThread causes many tests to timeout on Windows

Reviewed-by: dholmes, alanb

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

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

From jiangli at openjdk.org  Tue Mar 18 17:59:09 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Mar 2025 17:59:09 GMT
Subject: RFR: 8352098: -Xrunjdwp fails on static JDK [v2]
In-Reply-To: <BTgh3KcLu1UcaxABDb9FPc2advPQ69YI9TJmIEAb4LQ=.233707ea-fade-4d9f-863d-9a9640aad327@github.com>
References: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
 <Cwaj85vMP7yUW93kVr5G1Np9r70HXeqruZITD3JPKkU=.90b4dded-04c6-4357-9b27-4680a8f99ce0@github.com>
 <BTgh3KcLu1UcaxABDb9FPc2advPQ69YI9TJmIEAb4LQ=.233707ea-fade-4d9f-863d-9a9640aad327@github.com>
Message-ID: <XiFwWu4hS_Bue0fiof5lyEOQIO9zAKHFKE5QNOKbt58=.35de4b0b-280b-4ff2-a89a-2a4a7f88d07d@github.com>

On Tue, 18 Mar 2025 17:43:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I had a look yesterday and it looked good, and your latest changes look good also.

Thanks for reviewing, @plummercj!

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

PR Comment: https://git.openjdk.org/jdk/pull/24086#issuecomment-2734232834

From amenkov at openjdk.org  Tue Mar 18 18:02:12 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 18:02:12 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
Message-ID: <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>

On Tue, 18 Mar 2025 09:21:42 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> LGTM. Thanks for fixing it so quickly! Should `reply_writer` get implemented? We could file an RFE.

Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2734237925

From amenkov at openjdk.org  Tue Mar 18 18:02:13 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 18:02:13 GMT
Subject: Integrated: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
Message-ID: <MpPs7pw_KxIE4BdpjAj2QPK91M5lioM65e64g6x2UuY=.85abcb7a-9230-44b7-bef1-c9ac0fd3e360@github.com>

On Mon, 17 Mar 2025 20:35:58 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes crash on AIX after JDK-8319055
> Can't test it on AIX, but the reason is obvious from the stack trace.
> AIX is the only platform that does not implement `reply_writer` yet
> 
> Testing: sanity tier1

This pull request has now been integrated.

Changeset: a3540be5
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3540be502ef2f93c0fdc3fb2496c29ae7c8b041
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8352163: [AIX] SIGILL in AttachOperation::ReplyWriter::write_fully after 8319055

Reviewed-by: dholmes, mdoerr

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

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

From jiangli at openjdk.org  Tue Mar 18 19:07:12 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 18 Mar 2025 19:07:12 GMT
Subject: Integrated: 8352098: -Xrunjdwp fails on static JDK
In-Reply-To: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
References: <7AZV4Zx94USyWGyA2H3pu6-8Vo-ZM5or6AinLiC5MtM=.b770bcf8-00c0-4f73-a204-8009b6c70e26@github.com>
Message-ID: <QclIgJS1lEG7OfRYTca0Z1an75FagtgEFf9_mZrFD3A=.997f74ff-3c86-4f78-91f5-4cc7eda58e68@github.com>

On Mon, 17 Mar 2025 19:37:48 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this fix that avoids `JvmtiAgent::convert_xrun_agent` from prematurely exiting VM if `lookup_On_Load_entry_point` cannot load the agent using `JVM_OnLoad` symbol. Thanks
> 
> `lookup_On_Load_entry_point` first tries to load the builtin agent from the executable by checking the requested symbol (`JVM_OnLoad`). If no builtin agent is found, it then tries to load the agent shared library (e.g. `libjdwp.so`) by calling `load_library`. The issue is that `load_library` is called with `vm_exit_on_error` set to `true`, which causes the VM to exit immediately if the agent shared library is not loaded. Therefore, `JvmtiAgent::convert_xrun_agent` has no chance to try loading the agent using `Agent_OnLoad` symbol (https://github.com/openjdk/jdk/blob/19154f7af34bf6f13d61d7a9f05d6277964845d8/src/hotspot/share/prims/jvmtiAgent.cpp#L352). This is a hidden issue on regular JDK, since the `load_library` can successfully find the agent shared library when `JvmtiAgent::convert_xrun_agent` first tries to load the agent using `JVM_OnLoad` symbol. The issue is noticed on static JDK as there is no `libjdwp.so` in static JDK. It can be reproduced with jtreg `runtime/6294277/Sou
 rceDebugExtension.java` test.
> 
> As part of the fix, I cleaned up following in `invoke_JVM_OnLoad` and `invoke_Agent_OnLoad`. If there's an error, the VM should already have exited during `lookup_<JVM|Agent>_OnLoad_entry_point` in those cases.
> 
> 
>   if (on_load_entry == nullptr) {
>     vm_exit_during_initialization("Could not find ... function in -Xrun library", agent->name());
>   }

This pull request has now been integrated.

Changeset: 4a02de82
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a02de82923545f18590f8509c55129a4aa20842
Stats:     33 lines in 1 file changed: 11 ins; 6 del; 16 mod

8352098: -Xrunjdwp fails on static JDK

Reviewed-by: cjplummer, dholmes

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

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

From mdoerr at openjdk.org  Tue Mar 18 21:59:13 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 18 Mar 2025 21:59:13 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
 <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
Message-ID: <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>

On Tue, 18 Mar 2025 17:57:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)

@alexmenkov: The test serviceability/attach/AttachAPIv2/StreamingOutputTest.java is failing, now. So we need to address that. Should we problem-list it or better implement it now?

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2734831417

From amenkov at openjdk.org  Tue Mar 18 22:22:21 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 18 Mar 2025 22:22:21 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
 <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
 <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>
Message-ID: <4eJoZRoVRJY_DoMzGO496dvrWmgkvatgbwMMV0L3AqI=.fb2c028d-bb13-4415-b372-6c63973f1a1d@github.com>

On Tue, 18 Mar 2025 21:56:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)
> 
> @alexmenkov: The test serviceability/attach/AttachAPIv2/StreamingOutputTest.java is failing, now. So we need to address that. Should we problem-list it or better implement it now?

I think it's simpler to problem-list it on aix for now

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2734865489

From mdoerr at openjdk.org  Wed Mar 19 10:03:14 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 19 Mar 2025 10:03:14 GMT
Subject: RFR: 8352163: [AIX] SIGILL in
 AttachOperation::ReplyWriter::write_fully after 8319055
In-Reply-To: <4eJoZRoVRJY_DoMzGO496dvrWmgkvatgbwMMV0L3AqI=.fb2c028d-bb13-4415-b372-6c63973f1a1d@github.com>
References: <QI-aKAwMmq-neHt9q-6fCHqXjPee_BgofOfL15fE5S8=.cfa4c912-ccea-4be1-b27a-15b8e52bc2f5@github.com>
 <iR0Q4svRHyuce83k4th8na3CGkJ0MNnxZEq6Maji860=.61c4f6dc-966e-4bec-b4a4-8d58c83ad6d0@github.com>
 <mJpVFOBVQCgHSQDyFOqvq6mUkVLHTcGctxpl9Tv40Gw=.b16fadaf-2320-4c65-8ccf-0556c3e5ced4@github.com>
 <kQ_qsKI8vA9SEpo_CSw_ikBXX3lzzgtVhOSPmRoCwJc=.5185511e-9523-441b-8dd1-f350981d5d3f@github.com>
 <4eJoZRoVRJY_DoMzGO496dvrWmgkvatgbwMMV0L3AqI=.fb2c028d-bb13-4415-b372-6c63973f1a1d@github.com>
Message-ID: <7-a_AEEfT6p2tMwKNsRDs2rslfuvuPqAa9yfB_d0Mb4=.51c8a1bf-353b-4673-92a1-3847d7dbcec1@github.com>

On Tue, 18 Mar 2025 22:19:53 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> > > Yes, AIX implementation needs update (it does not support attach API v2 and streaming output). I was going to file RFE after the code is stabilized (AIX implementation is basically the same as posix implementation)
> > 
> > 
> > @alexmenkov: The test serviceability/attach/AttachAPIv2/StreamingOutputTest.java is failing, now. So we need to address that. Should we problem-list it or better implement it now?
> 
> I think it's simpler to problem-list it on aix for now

Thanks! I've filed https://bugs.openjdk.org/browse/JDK-8352392 and a subtask for problem-listing. Feel free to update it or add information. Please let us know when we should start implementing it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24089#issuecomment-2736005354

From sspitsyn at openjdk.org  Wed Mar 19 21:21:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 19 Mar 2025 21:21:07 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
Message-ID: <cUtpoeWEIumpt-5YrGofi7jBd8oD_TvXUCphSkn4W3g=.4ceaef45-c55a-405d-829b-01c124d92156@github.com>

On Thu, 13 Mar 2025 19:02:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk_jvmti_setFailStatus() sometimes is called after test check results. In these cases the warning logs are generated and hide the real failure reasons. Also, I think it is a error-prone way to set and check error, since check might be just forgotten. Also, the test execution after failure might be incorrect and also make failure analysis harder.
> So I think it makes sense to always fail when nsk_jvmti_setFailStatus() is called.
> 
> If this is going to work I'll rename it later and add add optional message to be more informative.

The fix looks okay in general. I've posted one comment about typos and one question.

test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 157:

> 155:       NSK_DISPLAY0("CompiledMethodLoad event recieved in dead phase");
> 156:       return;
> 157:     }

Nit: Typos at L148: `GetMethodNamme` => `GetMethodName`, `is work` => `works`, `phasem` => `phase`
A suggestion is to reformulate the comment as below:

    // GetMethodName works in live phase only so just exit if the event is generated too late


Also, I wonder if we want to abort/fail in all cases when `phase == JVMTI_PHASE_DEAD`.

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

PR Review: https://git.openjdk.org/jdk/pull/24040#pullrequestreview-2700233519
PR Review Comment: https://git.openjdk.org/jdk/pull/24040#discussion_r2004307114

From ihse at openjdk.org  Thu Mar 20 12:41:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 12:41:16 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
 <-XbY66kAbuHbUEu3cx7DCnvvo0KxERuZxJ65XthpHys=.3d44f448-9ebd-4f69-9221-dd0953e5b44e@github.com>
Message-ID: <XyhYFDGqhNF3GGb25Ii26L_8rLp2U-U6Mwetq-DVbgI=.26a4edcb-4894-45f8-bc7c-39fbe6cbb359@github.com>

On Mon, 17 Mar 2025 10:44:30 GMT, snake66 <duke at openjdk.org> wrote:

>>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
>> 
>> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
>> 
>>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.
>> 
>> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.
>
>> > Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
>> 
>> (...) I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
> 
> I'm happy to test this, if you want. Won't have time this week, though.

@snake66 No need, I'm already on it: https://github.com/openjdk/jdk/pull/24130

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2740320801

From ihse at openjdk.org  Thu Mar 20 12:41:17 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 20 Mar 2025 12:41:17 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
Message-ID: <ixZ9SLMOQWtl_teCR2Q3kwGO0Z8eAM9dudHAv-XurYk=.41357e07-aabe-480b-acc2-f7426cf0f8ea@github.com>

On Mon, 17 Mar 2025 06:41:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @magicus why can't we just use `-pthread` everywhere? My recollection is that `-pthread` both sets compiler directives needed for pthread programming and links to libpthread, so it seems to be what we should be using. ??
>
>> Another follow-up is if it would hurt to include $LIBPTHREAD for _all_ Hotspot tests, to avoid the huge list. @dholmes-ora Do you have anything coming to mind directly that would make that infeasible, or is it just a matter of testing to add it and see if any tests fail?
> 
> Sorry I was out of contact for a while. I can't imagine why any test would fail if linked with libpthread, given the VM is linking to it anyway.
> 
>> We can then check if we can turn -lpthread into -pthread on Linux as a follow up.
> 
> I have a vague recollection that at one time `-pthread` set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

@dholmes-ora 
> I have a vague recollection that at one time -pthread set some _POSIX_SOURCE define (or something like that) which conflicted with our use of some gcc specific things. But that was long ago so I would try it and see. Of couise it then becomes hard to classify what kind of flag this is because it isn't strictly a library flag.

Is there any gain then in changing away from `-lpthread`? That is clearly defined, link with libpthread, with no side effects. "If it ain't broke..."

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2740323348

From kevinw at openjdk.org  Thu Mar 20 14:45:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 20 Mar 2025 14:45:45 GMT
Subject: RFR: 8351224: Deprecate com.sun.tools.attach.AttachPermission for
 removal
Message-ID: <1A0Lh6G3_73k8ZErT3Bs5kPvoipkW6T-Ss2nBAT_0jQ=.81859d22-0485-44d0-bb6b-e3efd025bc46@github.com>

Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

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

Commit messages:
 - 8351224: Deprecate jdk.attach/share/classes/com/sun/tools/attach/AttachPermission.java for removal

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

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

From kevinw at openjdk.org  Thu Mar 20 14:48:45 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 20 Mar 2025 14:48:45 GMT
Subject: RFR: 8351310: Deprecate com.sun.jdi.JDIPermission for removal
Message-ID: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>

Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

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

Commit messages:
 - 8351310: Deprecate jdk.jdi/share/classes/com/sun/jdi/JDIPermission.java for removal

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

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

From sspitsyn at openjdk.org  Thu Mar 20 16:20:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Mar 2025 16:20:08 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <cUtpoeWEIumpt-5YrGofi7jBd8oD_TvXUCphSkn4W3g=.4ceaef45-c55a-405d-829b-01c124d92156@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
 <cUtpoeWEIumpt-5YrGofi7jBd8oD_TvXUCphSkn4W3g=.4ceaef45-c55a-405d-829b-01c124d92156@github.com>
Message-ID: <PvbsRWWmcN6Ed8bG2_szy4rUXOsvJV0XsCD8vW3odiI=.8ba0d595-1202-48d8-9008-696251543027@github.com>

On Wed, 19 Mar 2025 21:10:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> Also, I wonder if we want to abort/fail in all cases when phase == JVMTI_PHASE_DEAD.

I take it back. My suggestion does not look right.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24040#discussion_r2006007292

From sspitsyn at openjdk.org  Thu Mar 20 20:04:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Mar 2025 20:04:12 GMT
Subject: RFR: 8351224: Deprecate com.sun.tools.attach.AttachPermission for
 removal
In-Reply-To: <1A0Lh6G3_73k8ZErT3Bs5kPvoipkW6T-Ss2nBAT_0jQ=.81859d22-0485-44d0-bb6b-e3efd025bc46@github.com>
References: <1A0Lh6G3_73k8ZErT3Bs5kPvoipkW6T-Ss2nBAT_0jQ=.81859d22-0485-44d0-bb6b-e3efd025bc46@github.com>
Message-ID: <sPXa4Jsoe_yFeJ9bKhq08c7kQkuhfhPM7J0bUgivtug=.760d2029-ea95-4b68-9091-2ba9b45a5eea@github.com>

On Thu, 20 Mar 2025 14:27:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24133#pullrequestreview-2703961255

From sspitsyn at openjdk.org  Thu Mar 20 20:12:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 20 Mar 2025 20:12:07 GMT
Subject: RFR: 8351310: Deprecate com.sun.jdi.JDIPermission for removal
In-Reply-To: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
References: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
Message-ID: <s-xXeoxuo3Tx8YE8ZkAoYwjroOkdUrxN0nO1KmVgjD0=.d44606eb-f89f-4552-b184-d3e8cfed7813@github.com>

On Thu, 20 Mar 2025 14:23:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24132#pullrequestreview-2703977076

From cjplummer at openjdk.org  Thu Mar 20 20:33:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Mar 2025 20:33:06 GMT
Subject: RFR: 8351310: Deprecate com.sun.jdi.JDIPermission for removal
In-Reply-To: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
References: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
Message-ID: <DmlOFQUyeIqgmmvfqiLlM_s9IMkHf5VenDQ2UaIZnwc=.fd0c5b99-80e9-49bf-bac7-9c4b3e25d0e2@github.com>

On Thu, 20 Mar 2025 14:23:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24132#pullrequestreview-2704037994

From lmesnik at openjdk.org  Thu Mar 20 23:27:45 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 20 Mar 2025 23:27:45 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
Message-ID: <2r_6E9BFYZznu8xtGtQliNqiqFrK7Fv7RsGWvTeWyW0=.67cef91d-7c1a-4a0f-93b2-5841c1fda050@github.com>

> The nsk_jvmti_setFailStatus() sometimes is called after test check results. In these cases the warning logs are generated and hide the real failure reasons. Also, I think it is a error-prone way to set and check error, since check might be just forgotten. Also, the test execution after failure might be incorrect and also make failure analysis harder.
> So I think it makes sense to always fail when nsk_jvmti_setFailStatus() is called.
> 
> If this is going to work I'll rename it later and add add optional message to be more informative.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  comment updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24040/files
  - new: https://git.openjdk.org/jdk/pull/24040/files/5982af70..5dae85f1

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

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

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

From cjplummer at openjdk.org  Thu Mar 20 23:54:07 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 20 Mar 2025 23:54:07 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <2r_6E9BFYZznu8xtGtQliNqiqFrK7Fv7RsGWvTeWyW0=.67cef91d-7c1a-4a0f-93b2-5841c1fda050@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
 <2r_6E9BFYZznu8xtGtQliNqiqFrK7Fv7RsGWvTeWyW0=.67cef91d-7c1a-4a0f-93b2-5841c1fda050@github.com>
Message-ID: <MTiyUpRVG4m_5XXjE2lihOQPxXF1c9wcunYkdb2Ije0=.01c070cd-7e56-4207-8afa-9155459b0ec3@github.com>

On Thu, 20 Mar 2025 23:27:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The nsk_jvmti_setFailStatus() sometimes is called after test check results. In these cases the warning logs are generated and hide the real failure reasons. Also, I think it is a error-prone way to set and check error, since check might be just forgotten. Also, the test execution after failure might be incorrect and also make failure analysis harder.
>> So I think it makes sense to always fail when nsk_jvmti_setFailStatus() is called.
>> 
>> If this is going to work I'll rename it later and add add optional message to be more informative.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment updated

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24040#pullrequestreview-2704378042

From dholmes at openjdk.org  Fri Mar 21 03:20:22 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 21 Mar 2025 03:20:22 GMT
Subject: RFR: 8351322: Parameterize link option for pthreads [v2]
In-Reply-To: <ixZ9SLMOQWtl_teCR2Q3kwGO0Z8eAM9dudHAv-XurYk=.41357e07-aabe-480b-acc2-f7426cf0f8ea@github.com>
References: <H9gwN7pvCVIlcPMJTfsfU0OfDKZoWEltDd9yzJoc37g=.01f608c4-ab44-4fa3-b337-635a64aac65d@github.com>
 <PH-HDtzFcneQyVEHdaqUFSKOW6ahvpCjduEQQMbXpcY=.55f49b5a-b260-4a7c-b8ed-e6554bc208d5@github.com>
 <MI_ckk51OLQx9ntk_4m-hOfY9Ky_QAfnxdZI2EqNpC0=.4bf04ee4-519c-4ab5-ab41-20318fd9dd3b@github.com>
 <4X3eTA6KufGk9nATdqJ4Buwc0-nloZKgjdbvxZ0wH0U=.a71692bf-be51-49bb-9b35-a60d218e011f@github.com>
 <sM8NYCn-3RqYIlJ-Nx4W_9RqpCQFhzwECI-Il5tgvw4=.8b7e70bd-8b75-4522-9cf8-b81f5ec7a734@github.com>
 <ixZ9SLMOQWtl_teCR2Q3kwGO0Z8eAM9dudHAv-XurYk=.41357e07-aabe-480b-acc2-f7426cf0f8ea@github.com>
Message-ID: <oO-zMm8UBBW6kmetvoS96HZtfW5muMCUKehouJ9iZnI=.2fe3b007-5780-439e-aec1-acdcd6210ce1@github.com>

On Thu, 20 Mar 2025 12:38:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Is there any gain then in changing away from -lpthread? That is clearly defined, link with libpthread, with no side effects. "If it ain't broke..."

True - what we have works and using `-pthread` might subtly change things.

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

PR Comment: https://git.openjdk.org/jdk/pull/23930#issuecomment-2742145168

From lmesnik at openjdk.org  Sat Mar 22 00:17:06 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 22 Mar 2025 00:17:06 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <PvbsRWWmcN6Ed8bG2_szy4rUXOsvJV0XsCD8vW3odiI=.8ba0d595-1202-48d8-9008-696251543027@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
 <cUtpoeWEIumpt-5YrGofi7jBd8oD_TvXUCphSkn4W3g=.4ceaef45-c55a-405d-829b-01c124d92156@github.com>
 <PvbsRWWmcN6Ed8bG2_szy4rUXOsvJV0XsCD8vW3odiI=.8ba0d595-1202-48d8-9008-696251543027@github.com>
Message-ID: <asTwQ4yif2-tUFvlgvM4OAA-SkCgCvUV-_wbv4-Ml2s=.b82d48b9-0f42-49ed-9b32-a2d7142c802e@github.com>

On Thu, 20 Mar 2025 16:17:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/hotswap/HotSwap.cpp line 157:
>> 
>>> 155:       NSK_DISPLAY0("CompiledMethodLoad event recieved in dead phase");
>>> 156:       return;
>>> 157:     }
>> 
>> Nit: Typos at L148: `GetMethodNamme` => `GetMethodName`, `is work` => `works`, `phasem` => `phase`
>> A suggestion is to reformulate the comment as below:
>> 
>>     // GetMethodName works in live phase only so just exit if the event is generated too late
>> 
>> 
>> Also, I wonder if we want to abort/fail in all cases when `phase == JVMTI_PHASE_DEAD`.
>
>> Also, I wonder if we want to abort/fail in all cases when phase == JVMTI_PHASE_DEAD.
> 
> I take it back. My suggestion does not look right.

comment fixed.
I haven't find in spec that event can't be generated in dead phase. So test should just ignore this event.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24040#discussion_r2008497470

From sspitsyn at openjdk.org  Sat Mar 22 01:38:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 22 Mar 2025 01:38:16 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <2r_6E9BFYZznu8xtGtQliNqiqFrK7Fv7RsGWvTeWyW0=.67cef91d-7c1a-4a0f-93b2-5841c1fda050@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
 <2r_6E9BFYZznu8xtGtQliNqiqFrK7Fv7RsGWvTeWyW0=.67cef91d-7c1a-4a0f-93b2-5841c1fda050@github.com>
Message-ID: <QJYNXShv47NvWPERGuWCLfA_Z5lnv66IQalIu3zItAs=.0ebad0c1-d0ba-4336-b95b-e0475f261000@github.com>

On Thu, 20 Mar 2025 23:27:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The nsk_jvmti_setFailStatus() sometimes is called after test check results. In these cases the warning logs are generated and hide the real failure reasons. Also, I think it is a error-prone way to set and check error, since check might be just forgotten. Also, the test execution after failure might be incorrect and also make failure analysis harder.
>> So I think it makes sense to always fail when nsk_jvmti_setFailStatus() is called.
>> 
>> If this is going to work I'll rename it later and add add optional message to be more informative.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment updated

Thank you for the update! LGTM.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24040#pullrequestreview-2707723738

From lmesnik at openjdk.org  Sat Mar 22 02:03:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 22 Mar 2025 02:03:11 GMT
Subject: Integrated: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
Message-ID: <BVw9cxfznykPjnMHG5nV2uZSeYqJWqHuixJZtZd4OUw=.12855571-3913-49b7-9c6c-e29d51532d25@github.com>

On Thu, 13 Mar 2025 19:02:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The nsk_jvmti_setFailStatus() sometimes is called after test check results. In these cases the warning logs are generated and hide the real failure reasons. Also, I think it is a error-prone way to set and check error, since check might be just forgotten. Also, the test execution after failure might be incorrect and also make failure analysis harder.
> So I think it makes sense to always fail when nsk_jvmti_setFailStatus() is called.
> 
> If this is going to work I'll rename it later and add add optional message to be more informative.

This pull request has now been integrated.

Changeset: 334a1eec
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/334a1eec2375a4f9f3150bdb556c1c2432596b4b
Stats:     70 lines in 5 files changed: 46 ins; 19 del; 5 mod

8351375: nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called

Reviewed-by: sspitsyn, cjplummer

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

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

From varadam at openjdk.org  Sun Mar 23 15:54:44 2025
From: varadam at openjdk.org (Varada M)
Date: Sun, 23 Mar 2025 15:54:44 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
Message-ID: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>

AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes

tier1, tier2 and tier3 testing is successful with fastdebug level

JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

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

Commit messages:
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: Problem list serviceability/attach/AttachAPIv2/StreamingOutputTest.java

Changes: https://git.openjdk.org/jdk/pull/24177/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352392
  Stats: 279 lines in 2 files changed: 63 ins; 201 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24177/head:pull/24177

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

From dholmes at openjdk.org  Sun Mar 23 22:09:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 23 Mar 2025 22:09:12 GMT
Subject: RFR: 8351375: nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called [v2]
In-Reply-To: <2r_6E9BFYZznu8xtGtQliNqiqFrK7Fv7RsGWvTeWyW0=.67cef91d-7c1a-4a0f-93b2-5841c1fda050@github.com>
References: <s3M0t3C7EFjhZdYtiVSmoPU8c-w9bMP9yRBUSXfV9wI=.0551d564-ad6e-4d8b-b268-4cd752b32d92@github.com>
 <2r_6E9BFYZznu8xtGtQliNqiqFrK7Fv7RsGWvTeWyW0=.67cef91d-7c1a-4a0f-93b2-5841c1fda050@github.com>
Message-ID: <CbVRZd9vXZ2S4KkOGMOO3tJH9oqCG5lzV2zjydbgeDI=.e9d8818a-18e8-438d-b42d-e1cedfc6859c@github.com>

On Thu, 20 Mar 2025 23:27:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The nsk_jvmti_setFailStatus() sometimes is called after test check results. In these cases the warning logs are generated and hide the real failure reasons. Also, I think it is a error-prone way to set and check error, since check might be just forgotten. Also, the test execution after failure might be incorrect and also make failure analysis harder.
>> So I think it makes sense to always fail when nsk_jvmti_setFailStatus() is called.
>> 
>> If this is going to work I'll rename it later and add add optional message to be more informative.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment updated

There are a number of tier 5 failures after this change - filed [JDK-8352652](https://bugs.openjdk.org/browse/JDK-8352652)

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

PR Comment: https://git.openjdk.org/jdk/pull/24040#issuecomment-2746492882

From dholmes at openjdk.org  Mon Mar 24 00:15:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Mar 2025 00:15:37 GMT
Subject: RFR: 8352652: [BACKOUT] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
Message-ID: <zChnzHyVQZ7g8-yK-Apxg-VdvKyv8V5hnsxJah01CRc=.6ed7b777-8ec1-484b-8695-aaf396b6dda0@github.com>

Revert "8351375: nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called"

This reverts commit 334a1eec2375a4f9f3150bdb556c1c2432596b4b.

The original change caused numerous test failures.

Thanks

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

Commit messages:
 - Revert "8351375: nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called"

Changes: https://git.openjdk.org/jdk/pull/24181/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24181&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352652
  Stats: 70 lines in 5 files changed: 19 ins; 46 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/24181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24181/head:pull/24181

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

From lmesnik at openjdk.org  Mon Mar 24 00:15:37 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 24 Mar 2025 00:15:37 GMT
Subject: RFR: 8352652: [BACKOUT] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <zChnzHyVQZ7g8-yK-Apxg-VdvKyv8V5hnsxJah01CRc=.6ed7b777-8ec1-484b-8695-aaf396b6dda0@github.com>
References: <zChnzHyVQZ7g8-yK-Apxg-VdvKyv8V5hnsxJah01CRc=.6ed7b777-8ec1-484b-8695-aaf396b6dda0@github.com>
Message-ID: <nrmK6_dCB_5KKh2TYsEdN1v1hV8ZU_TDhjZtJ7II7ms=.b13c8e90-049d-45ff-99fd-fd9bde614ef9@github.com>

On Mon, 24 Mar 2025 00:09:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8351375: nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called"
> 
> This reverts commit 334a1eec2375a4f9f3150bdb556c1c2432596b4b.
> 
> The original change caused numerous test failures.
> 
> Thanks

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24181#pullrequestreview-2708877138

From dholmes at openjdk.org  Mon Mar 24 00:22:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Mar 2025 00:22:10 GMT
Subject: RFR: 8352652: [BACKOUT] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <nrmK6_dCB_5KKh2TYsEdN1v1hV8ZU_TDhjZtJ7II7ms=.b13c8e90-049d-45ff-99fd-fd9bde614ef9@github.com>
References: <zChnzHyVQZ7g8-yK-Apxg-VdvKyv8V5hnsxJah01CRc=.6ed7b777-8ec1-484b-8695-aaf396b6dda0@github.com>
 <nrmK6_dCB_5KKh2TYsEdN1v1hV8ZU_TDhjZtJ7II7ms=.b13c8e90-049d-45ff-99fd-fd9bde614ef9@github.com>
Message-ID: <0y6jZfcELAgwZqnho3fwLOka2PafwiY_TprEVTUjKUk=.02acf15d-a290-403a-a873-3ac1c815db0e@github.com>

On Mon, 24 Mar 2025 00:11:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Revert "8351375: nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called"
>> 
>> This reverts commit 334a1eec2375a4f9f3150bdb556c1c2432596b4b.
>> 
>> The original change caused numerous test failures.
>> 
>> Thanks
>
> Marked as reviewed by lmesnik (Reviewer).

Thanks @lmesnik !

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

PR Comment: https://git.openjdk.org/jdk/pull/24181#issuecomment-2746575743

From dholmes at openjdk.org  Mon Mar 24 00:22:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 24 Mar 2025 00:22:11 GMT
Subject: Integrated: 8352652: [BACKOUT] nsk/jvmti/ tests should fail when
 nsk_jvmti_setFailStatus() is called
In-Reply-To: <zChnzHyVQZ7g8-yK-Apxg-VdvKyv8V5hnsxJah01CRc=.6ed7b777-8ec1-484b-8695-aaf396b6dda0@github.com>
References: <zChnzHyVQZ7g8-yK-Apxg-VdvKyv8V5hnsxJah01CRc=.6ed7b777-8ec1-484b-8695-aaf396b6dda0@github.com>
Message-ID: <M2V3DauOv1QT3ef7y5fNUc8CAR_l-1BhLrFOiZsmMX8=.79341c2b-a5bf-4649-87b8-fafe02eb8438@github.com>

On Mon, 24 Mar 2025 00:09:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Revert "8351375: nsk/jvmti/ tests should fail when  nsk_jvmti_setFailStatus() is called"
> 
> This reverts commit 334a1eec2375a4f9f3150bdb556c1c2432596b4b.
> 
> The original change caused numerous test failures.
> 
> Thanks

This pull request has now been integrated.

Changeset: ee1577b7
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee1577b790cd29c0bee9f77829aa40d9e512e30f
Stats:     70 lines in 5 files changed: 19 ins; 46 del; 5 mod

8352652: [BACKOUT] nsk/jvmti/ tests should fail when nsk_jvmti_setFailStatus() is called

Reviewed-by: lmesnik

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

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

From kevinw at openjdk.org  Mon Mar 24 11:54:49 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Mar 2025 11:54:49 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests
 fail intermittently
Message-ID: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>

These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.

They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.

GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.

The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

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

Commit messages:
 - whitespace
 - problemlist
 - Merge remote-tracking branch 'upstream/master' into 8351002_OSMXBean_CPU_Tests
 - 8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently

Changes: https://git.openjdk.org/jdk/pull/24186/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351002
  Stats: 59 lines in 4 files changed: 44 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24186/head:pull/24186

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

From jkern at openjdk.org  Mon Mar 24 13:56:06 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 24 Mar 2025 13:56:06 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <9b9bUZ6_i0Mcb9N-zZXblDBTXKjGo8cbZnzIANaFVzk=.5823939c-56fc-4066-9b30-c162e4ae6929@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

Hi Varada, it looks to me that with your change you've brought the AIX code closer to the POSIX implementation, but not completely. Could you please explain your changes in detail so I can review the PR? I'm not that familiar with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2748211872

From aturbanov at openjdk.org  Mon Mar 24 14:56:10 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 24 Mar 2025 14:56:10 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <o4T4iQjlebKVYbC57dgxjCH3b0XLiiv8gpXWuT6KnYY=.d8ccc711-ac70-4d02-aaa0-90e8d8f11076@github.com>

On Mon, 24 Mar 2025 10:13:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 43:

> 41:         double load;
> 42: 
> 43:         for(int i = 0; i < 10; i++) {

Suggestion:

        for (int i = 0; i < 10; i++) {

test/jdk/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java line 43:

> 41:         double load;
> 42: 
> 43:         for(int i = 0; i < 10; i++) {

Suggestion:

        for (int i = 0; i < 10; i++) {

test/jdk/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java line 49:

> 47:                 // Remember a -1 in case it never gets better.
> 48:                 ex = new RuntimeException("getSystemCpuLoad() returns " + load
> 49:                          +  " which is not in the [0.0,1.0] interval");

Suggestion:

                         + " which is not in the [0.0,1.0] interval");

test/jdk/com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java line 53:

> 51:             } else if (load < 0.0 || load > 1.0) {
> 52:                 throw new RuntimeException("getSystemCpuLoad() returns " + load
> 53:                            +  " which is not in the [0.0,1.0] interval");

Suggestion:

                           + " which is not in the [0.0,1.0] interval");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010344429
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010344971
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010345618
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010346257

From kevinw at openjdk.org  Mon Mar 24 15:08:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Mar 2025 15:08:01 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v2]
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:

 - whitespace
 - whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24186/files
  - new: https://git.openjdk.org/jdk/pull/24186/files/21ebab5b..2cfd63ce

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

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

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

From duke at openjdk.org  Mon Mar 24 15:10:28 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 24 Mar 2025 15:10:28 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be protected
 by NMT lock
Message-ID: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>

### Summary:
This PR makes memory operations atomic with NMT accounting.

### The problem:
In memory related functions like `os::commit_memory` and `os::reserve_memory` the OS memory operations are currently done before acquiring the the NMT mutex. And the the virtual memory accounting is done later in `MemTracker`, after the lock has been acquired. Doing the memory operations outside of the lock scope can lead to races. 

1.1 Thread_1 releases range_A.
1.2 Thread_1 tells NMT "range_A has been released".

2.1 Thread_2 reserves (the now free) range_A.
2.2 Thread_2 tells NMT "range_A is reserved".

Since the sequence (1.1)  (1.2) is not atomic, if Thread_2 begins operating after (1.1), we can have (1.1) (2.1) (2.2) (1.2). The OS sees two valid subsequent calls (release range_A, followed by map range_A). But NMT sees "reserve range_A", "release range_A" and is now out of sync with the OS.

### Solution:
Where memory operations such as reserve, commit, or release virtual memory happen,  I've expanded the scope of `NmtVirtualMemoryLocker` to protect both the NMT accounting and the memory operation itself. 

### Other notes:
I also simplified this  pattern found in many places:

if (MemTracker::enabled()) {
  MemTracker::NmtVirtualMemoryLocker nvml;
  result = pd_some_operation(addr, bytes);
  if (result != nullptr) {
    MemTracker::record_some_operation(addr, bytes);
  }
} else {
  result = pd_unmap_memory(addr, bytes);
}
``` 
To:

MemTracker::NmtVirtualMemoryLocker nvml;
result = pd_unmap_memory(addr, bytes);
MemTracker::record_some_operation(addr, bytes);
``` 
This is possible because `NmtVirtualMemoryLocker` now checks `MemTracker::enabled()`.  `MemTracker::record_some_operation` already checks `MemTracker::enabled()` and checks against nullptr.  This refactoring previously wasn't possible because `ThreadCritical` was used before https://github.com/openjdk/jdk/pull/22745 introduced `NmtVirtualMemoryLocker`. 

I considered moving the locking and NMT accounting down into platform specific code:  Ex. lock around { munmap() + MemTracker::record }. The hope was that this would help reduce the size of the critical section. However, I found that the OS-specific "pd_" functions are already short and to-the-point, so doing this wasn't reducing the lock scope very much. Instead it just makes the code more messy by having to maintain the locking and NMT accounting in each platform specific implementation. 

In many places I've done minor refactoring by relocating calls to `MemTracker` in order to tighten the locking scope.

In some OS specific code (such as `os::map_memory_to_file`), I've replaced calls to `os::release_memory` with `os::pd_release_memory`. This is to avoid `NmtVirtualMemoryLocker` reentrancy.

In a few places (such as `VirtualMemoryTracker::add_reserved_region`) I have replaced `tty` with `defaultStream::output_stream()`. Otherwise `NmtVirtualMemory_lock` would be acquired out of rank order with  `tty_lock`. 

### Testing:
One concern, due to the expanded critical section, is reentrancy. `NmtVirtualMemoryLocker` is a HotSpot mutex and is not reentrant. I've added new tests in _test_os.cpp_ and _test_virtualMemoryTracker.cpp_ that try to exercise any usages of NMT that weren't already exercised by existing tests.

tier1 passes on linux and windows. I do not have an AIX machine to test on. Can someone please help run the tests on AIX?

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

Commit messages:
 - make memory op and NMT accounting atomic

Changes: https://git.openjdk.org/jdk/pull/24084/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341491
  Stats: 291 lines in 12 files changed: 186 ins; 42 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/24084.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24084/head:pull/24084

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

From stuefe at openjdk.org  Mon Mar 24 15:14:21 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 24 Mar 2025 15:14:21 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
Message-ID: <2QUUuzqu_F0eii8j8FqbFlBI-04SN8u6MT2jmOoPsYo=.88646953-2d89-40b8-9e24-fb870b154a8b@github.com>

On Mon, 17 Mar 2025 16:20:42 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary:
> This PR makes memory operations atomic with NMT accounting.
> 
> ### The problem:
> In memory related functions like `os::commit_memory` and `os::reserve_memory` the OS memory operations are currently done before acquiring the the NMT mutex. And the the virtual memory accounting is done later in `MemTracker`, after the lock has been acquired. Doing the memory operations outside of the lock scope can lead to races. 
> 
> 1.1 Thread_1 releases range_A.
> 1.2 Thread_1 tells NMT "range_A has been released".
> 
> 2.1 Thread_2 reserves (the now free) range_A.
> 2.2 Thread_2 tells NMT "range_A is reserved".
> 
> Since the sequence (1.1)  (1.2) is not atomic, if Thread_2 begins operating after (1.1), we can have (1.1) (2.1) (2.2) (1.2). The OS sees two valid subsequent calls (release range_A, followed by map range_A). But NMT sees "reserve range_A", "release range_A" and is now out of sync with the OS.
> 
> ### Solution:
> Where memory operations such as reserve, commit, or release virtual memory happen,  I've expanded the scope of `NmtVirtualMemoryLocker` to protect both the NMT accounting and the memory operation itself. 
> 
> ### Other notes:
> I also simplified this  pattern found in many places:
> 
> if (MemTracker::enabled()) {
>   MemTracker::NmtVirtualMemoryLocker nvml;
>   result = pd_some_operation(addr, bytes);
>   if (result != nullptr) {
>     MemTracker::record_some_operation(addr, bytes);
>   }
> } else {
>   result = pd_unmap_memory(addr, bytes);
> }
> ``` 
> To:
> 
> MemTracker::NmtVirtualMemoryLocker nvml;
> result = pd_unmap_memory(addr, bytes);
> MemTracker::record_some_operation(addr, bytes);
> ``` 
> This is possible because `NmtVirtualMemoryLocker` now checks `MemTracker::enabled()`.  `MemTracker::record_some_operation` already checks `MemTracker::enabled()` and checks against nullptr.  This refactoring previously wasn't possible because `ThreadCritical` was used before https://github.com/openjdk/jdk/pull/22745 introduced `NmtVirtualMemoryLocker`. 
> 
> I considered moving the locking and NMT accounting down into platform specific code:  Ex. lock around { munmap() + MemTracker::record }. The hope was that this would help reduce the size of the critical section. However, I found that the OS-specific "pd_" functions are already short and to-the-point, so doing this wasn't reducing the lock scope very much. Instead it just makes the code more messy by having to maintain the locking and NMT accounting in each platform specific implementation. 
> 
> In many places I've done minor refactoring by relocating call...

Ping @JoKern65 for AIX

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2748477402

From stefank at openjdk.org  Mon Mar 24 16:19:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 24 Mar 2025 16:19:20 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
Message-ID: <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>

On Mon, 17 Mar 2025 16:20:42 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary:
> This PR makes memory operations atomic with NMT accounting.
> 
> ### The problem:
> In memory related functions like `os::commit_memory` and `os::reserve_memory` the OS memory operations are currently done before acquiring the the NMT mutex. And the the virtual memory accounting is done later in `MemTracker`, after the lock has been acquired. Doing the memory operations outside of the lock scope can lead to races. 
> 
> 1.1 Thread_1 releases range_A.
> 1.2 Thread_1 tells NMT "range_A has been released".
> 
> 2.1 Thread_2 reserves (the now free) range_A.
> 2.2 Thread_2 tells NMT "range_A is reserved".
> 
> Since the sequence (1.1)  (1.2) is not atomic, if Thread_2 begins operating after (1.1), we can have (1.1) (2.1) (2.2) (1.2). The OS sees two valid subsequent calls (release range_A, followed by map range_A). But NMT sees "reserve range_A", "release range_A" and is now out of sync with the OS.
> 
> ### Solution:
> Where memory operations such as reserve, commit, or release virtual memory happen,  I've expanded the scope of `NmtVirtualMemoryLocker` to protect both the NMT accounting and the memory operation itself. 
> 
> ### Other notes:
> I also simplified this  pattern found in many places:
> 
> if (MemTracker::enabled()) {
>   MemTracker::NmtVirtualMemoryLocker nvml;
>   result = pd_some_operation(addr, bytes);
>   if (result != nullptr) {
>     MemTracker::record_some_operation(addr, bytes);
>   }
> } else {
>   result = pd_unmap_memory(addr, bytes);
> }
> ``` 
> To:
> 
> MemTracker::NmtVirtualMemoryLocker nvml;
> result = pd_unmap_memory(addr, bytes);
> MemTracker::record_some_operation(addr, bytes);
> ``` 
> This is possible because `NmtVirtualMemoryLocker` now checks `MemTracker::enabled()`.  `MemTracker::record_some_operation` already checks `MemTracker::enabled()` and checks against nullptr.  This refactoring previously wasn't possible because `ThreadCritical` was used before https://github.com/openjdk/jdk/pull/22745 introduced `NmtVirtualMemoryLocker`. 
> 
> I considered moving the locking and NMT accounting down into platform specific code:  Ex. lock around { munmap() + MemTracker::record }. The hope was that this would help reduce the size of the critical section. However, I found that the OS-specific "pd_" functions are already short and to-the-point, so doing this wasn't reducing the lock scope very much. Instead it just makes the code more messy by having to maintain the locking and NMT accounting in each platform specific implementation. 
> 
> In many places I've done minor refactoring by relocating call...

I don't see why we need to extend the lock to be held over the reserve/commit/alloc part.

If we only extend the lock on the release side, then it looks like we get the required exclusion:

lock
1.1 Thread_1 releases range_A.
1.2 Thread_1 tells NMT "range_A has been released".
unlock

2.1 Thread_2 reserves (the now free) range_A.
lock
2.2 Thread_2 tells NMT "range_A is reserved".
unlock

We can get ordering (1.1) (2.1) (1.2) (2.2) but we can't get (1.1) (2.1) (2.2) (1.2).

And isn't this locking scheme exactly what the current code is using? Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24084#pullrequestreview-2710963414

From stuefe at openjdk.org  Mon Mar 24 17:03:21 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 24 Mar 2025 17:03:21 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
Message-ID: <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>

On Mon, 24 Mar 2025 16:16:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> ### Summary:
>> This PR makes memory operations atomic with NMT accounting.
>> 
>> ### The problem:
>> In memory related functions like `os::commit_memory` and `os::reserve_memory` the OS memory operations are currently done before acquiring the the NMT mutex. And the the virtual memory accounting is done later in `MemTracker`, after the lock has been acquired. Doing the memory operations outside of the lock scope can lead to races. 
>> 
>> 1.1 Thread_1 releases range_A.
>> 1.2 Thread_1 tells NMT "range_A has been released".
>> 
>> 2.1 Thread_2 reserves (the now free) range_A.
>> 2.2 Thread_2 tells NMT "range_A is reserved".
>> 
>> Since the sequence (1.1)  (1.2) is not atomic, if Thread_2 begins operating after (1.1), we can have (1.1) (2.1) (2.2) (1.2). The OS sees two valid subsequent calls (release range_A, followed by map range_A). But NMT sees "reserve range_A", "release range_A" and is now out of sync with the OS.
>> 
>> ### Solution:
>> Where memory operations such as reserve, commit, or release virtual memory happen,  I've expanded the scope of `NmtVirtualMemoryLocker` to protect both the NMT accounting and the memory operation itself. 
>> 
>> ### Other notes:
>> I also simplified this  pattern found in many places:
>> 
>> if (MemTracker::enabled()) {
>>   MemTracker::NmtVirtualMemoryLocker nvml;
>>   result = pd_some_operation(addr, bytes);
>>   if (result != nullptr) {
>>     MemTracker::record_some_operation(addr, bytes);
>>   }
>> } else {
>>   result = pd_unmap_memory(addr, bytes);
>> }
>> ``` 
>> To:
>> 
>> MemTracker::NmtVirtualMemoryLocker nvml;
>> result = pd_unmap_memory(addr, bytes);
>> MemTracker::record_some_operation(addr, bytes);
>> ``` 
>> This is possible because `NmtVirtualMemoryLocker` now checks `MemTracker::enabled()`.  `MemTracker::record_some_operation` already checks `MemTracker::enabled()` and checks against nullptr.  This refactoring previously wasn't possible because `ThreadCritical` was used before https://github.com/openjdk/jdk/pull/22745 introduced `NmtVirtualMemoryLocker`. 
>> 
>> I considered moving the locking and NMT accounting down into platform specific code:  Ex. lock around { munmap() + MemTracker::record }. The hope was that this would help reduce the size of the critical section. However, I found that the OS-specific "pd_" functions are already short and to-the-point, so doing this wasn't reducing the lock scope very much. Instead it just makes the code more messy by having to maintain the locking and NMT accounting in each platform specific i...
>
> I don't see why we need to extend the lock to be held over the reserve/commit/alloc part.
> 
> If we only extend the lock on the release side, then it looks like we get the required exclusion:
> 
> lock
> 1.1 Thread_1 releases range_A.
> 1.2 Thread_1 tells NMT "range_A has been released".
> unlock
> 
> 2.1 Thread_2 reserves (the now free) range_A.
> lock
> 2.2 Thread_2 tells NMT "range_A is reserved".
> unlock
> 
> We can get ordering (1.1) (2.1) (1.2) (2.2) but we can't get (1.1) (2.1) (2.2) (1.2).
> 
> And isn't this locking scheme exactly what the current code is using? Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.

@stefank 

> And isn't this locking scheme exactly what the current code is using? Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.

What about the case where one thread reserves a range and another thread releases it? 

1 Thread A reserves range
2 Thread B releases range
3 Thread B tells NMT "range released"
4 Thread A tells NMT "range reserved"

This would either result in an assert in NMT at step 3 when releasing a range NMT does not know. Or in an incorrectly booked range in step 4 without asserts. Am I making a thinking error somewhere?

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2748815516

From duke at openjdk.org  Mon Mar 24 17:14:14 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 24 Mar 2025 17:14:14 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
Message-ID: <C9OKyQ0atpiaviMrIm7tWHpGoCbO1FXuyX6ieV7eH1g=.55ffcdc9-cdd8-4174-a3ad-fb69f1c78a46@github.com>

On Mon, 24 Mar 2025 16:16:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> ### Summary:
>> This PR makes memory operations atomic with NMT accounting.
>> 
>> ### The problem:
>> In memory related functions like `os::commit_memory` and `os::reserve_memory` the OS memory operations are currently done before acquiring the the NMT mutex. And the the virtual memory accounting is done later in `MemTracker`, after the lock has been acquired. Doing the memory operations outside of the lock scope can lead to races. 
>> 
>> 1.1 Thread_1 releases range_A.
>> 1.2 Thread_1 tells NMT "range_A has been released".
>> 
>> 2.1 Thread_2 reserves (the now free) range_A.
>> 2.2 Thread_2 tells NMT "range_A is reserved".
>> 
>> Since the sequence (1.1)  (1.2) is not atomic, if Thread_2 begins operating after (1.1), we can have (1.1) (2.1) (2.2) (1.2). The OS sees two valid subsequent calls (release range_A, followed by map range_A). But NMT sees "reserve range_A", "release range_A" and is now out of sync with the OS.
>> 
>> ### Solution:
>> Where memory operations such as reserve, commit, or release virtual memory happen,  I've expanded the scope of `NmtVirtualMemoryLocker` to protect both the NMT accounting and the memory operation itself. 
>> 
>> ### Other notes:
>> I also simplified this  pattern found in many places:
>> 
>> if (MemTracker::enabled()) {
>>   MemTracker::NmtVirtualMemoryLocker nvml;
>>   result = pd_some_operation(addr, bytes);
>>   if (result != nullptr) {
>>     MemTracker::record_some_operation(addr, bytes);
>>   }
>> } else {
>>   result = pd_unmap_memory(addr, bytes);
>> }
>> ``` 
>> To:
>> 
>> MemTracker::NmtVirtualMemoryLocker nvml;
>> result = pd_unmap_memory(addr, bytes);
>> MemTracker::record_some_operation(addr, bytes);
>> ``` 
>> This is possible because `NmtVirtualMemoryLocker` now checks `MemTracker::enabled()`.  `MemTracker::record_some_operation` already checks `MemTracker::enabled()` and checks against nullptr.  This refactoring previously wasn't possible because `ThreadCritical` was used before https://github.com/openjdk/jdk/pull/22745 introduced `NmtVirtualMemoryLocker`. 
>> 
>> I considered moving the locking and NMT accounting down into platform specific code:  Ex. lock around { munmap() + MemTracker::record }. The hope was that this would help reduce the size of the critical section. However, I found that the OS-specific "pd_" functions are already short and to-the-point, so doing this wasn't reducing the lock scope very much. Instead it just makes the code more messy by having to maintain the locking and NMT accounting in each platform specific i...
>
> I don't see why we need to extend the lock to be held over the reserve/commit/alloc part.
> 
> If we only extend the lock on the release side, then it looks like we get the required exclusion:
> 
> lock
> 1.1 Thread_1 releases range_A.
> 1.2 Thread_1 tells NMT "range_A has been released".
> unlock
> 
> 2.1 Thread_2 reserves (the now free) range_A.
> lock
> 2.2 Thread_2 tells NMT "range_A is reserved".
> unlock
> 
> We can get ordering (1.1) (2.1) (1.2) (2.2) but we can't get (1.1) (2.1) (2.2) (1.2).
> 
> And isn't this locking scheme exactly what the current code is using? Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.

Hi @stefank, I think you're right about (1.1) (2.1) (2.2) (1.2) being prevented by the current implementation. Is there a reason that the current implementation only does the wider locking for release/uncommit? Maybe (2.1) (1.1) (1.2) (2.2) isn't much of an issue since it's unlikely that another thread would uncommit/release the same base address shortly after it's committed/reserved? 

>Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.

I haven't seen that race in the wild, I just noticed that the memory operations weren't protected and thought that it could be a problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2748848175

From lmesnik at openjdk.org  Mon Mar 24 20:15:14 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 24 Mar 2025 20:15:14 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v2]
In-Reply-To: <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
Message-ID: <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>

On Mon, 24 Mar 2025 15:08:01 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - whitespace
>  - whitespace

Changes requested by lmesnik (Reviewer).

test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 45:

> 43:         for(int i = 0; i < 10; i++) {
> 44:             load = mbean.getProcessCpuLoad();
> 45:             if (load == -1.0) {

Please harden test to allow -1.0 on windows only.

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

PR Review: https://git.openjdk.org/jdk/pull/24186#pullrequestreview-2711575803
PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010862043

From kevinw at openjdk.org  Mon Mar 24 21:55:20 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 24 Mar 2025 21:55:20 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v2]
In-Reply-To: <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
 <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>
Message-ID: <Nuae5iinBMnoKQV7CwVUhoT0UJ4IENAM7nU0xDXLa0c=.4574af58-c77f-469c-b686-aebf92679696@github.com>

On Mon, 24 Mar 2025 20:12:45 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - whitespace
>>  - whitespace
>
> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 45:
> 
>> 43:         for(int i = 0; i < 10; i++) {
>> 44:             load = mbean.getProcessCpuLoad();
>> 45:             if (load == -1.0) {
> 
> Please harden test to allow -1.0 on windows only.

Thanks yes I was considering that, then I thought it seemed fair to me to permit all platforms to return -1, and as long as they start returning valid values, the test will pass.
But we could make it stricter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2010975156

From sspitsyn at openjdk.org  Tue Mar 25 09:01:51 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 25 Mar 2025 09:01:51 GMT
Subject: RFR: 8352812: remove useless class and function parameter in
 SuspendThread impl
Message-ID: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>

The internal class JvmtiSuspendControl is transitively used in the SuspendThread implementation is not really needed and is being removed. Also, the suspend_thread function has unused need_safepoint_p parameter which is being removed as well.

Testing:
 - TBD: Run mach5 tiers 1-3 to be safe

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

Commit messages:
 - 8352812: remove useless class and function parameter in SuspendThread impl

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

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

From kevinw at openjdk.org  Tue Mar 25 11:21:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 11:21:28 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v3]
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  stricter check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24186/files
  - new: https://git.openjdk.org/jdk/pull/24186/files/2cfd63ce..453faf4d

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

  Stats: 25 lines in 3 files changed: 7 ins; 2 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/24186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24186/head:pull/24186

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

From kevinw at openjdk.org  Tue Mar 25 11:58:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 11:58:26 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v2]
In-Reply-To: <Nuae5iinBMnoKQV7CwVUhoT0UJ4IENAM7nU0xDXLa0c=.4574af58-c77f-469c-b686-aebf92679696@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <HW-VMY0YpceF_YHYSXTmQ8XeNo8-F-cptJ7NWuNOPqQ=.550b1731-1574-4fdc-a083-1383c08112c9@github.com>
 <t0C4hfB32hWWHXD9_ybOweLJq9zVyvSKeq_w28FXTCM=.85e76b92-bc56-48bc-92c3-b13ae78590ba@github.com>
 <Nuae5iinBMnoKQV7CwVUhoT0UJ4IENAM7nU0xDXLa0c=.4574af58-c77f-469c-b686-aebf92679696@github.com>
Message-ID: <RS9GK1FXVcYAILIGS_mWSwFiVag38sa2O07SwsBKxh4=.f12cfa8c-fa9f-4707-a4c1-41ac00321ce5@github.com>

On Mon, 24 Mar 2025 21:52:41 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java line 45:
>> 
>>> 43:         for(int i = 0; i < 10; i++) {
>>> 44:             load = mbean.getProcessCpuLoad();
>>> 45:             if (load == -1.0) {
>> 
>> Please harden test to allow -1.0 on windows only.
>
> Thanks yes I was considering that, then I thought it seemed fair to me to permit all platforms to return -1, and as long as they start returning valid values, the test will pass.
> But we could make it stricter.

Updated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2011933784

From kevinw at openjdk.org  Tue Mar 25 12:35:19 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 12:35:19 GMT
Subject: RFR: 8351310: Deprecate com.sun.jdi.JDIPermission for removal
In-Reply-To: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
References: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
Message-ID: <nUNPimQdbwLq-RFoKeN3jNr_nL67fGylsUNdsNPdDow=.45b248c0-074e-4fad-9ac3-47cb729c3012@github.com>

On Thu, 20 Mar 2025 14:23:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24132#issuecomment-2751105353

From kevinw at openjdk.org  Tue Mar 25 12:35:19 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 12:35:19 GMT
Subject: Integrated: 8351310: Deprecate com.sun.jdi.JDIPermission for removal
In-Reply-To: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
References: <PrLvfyXo1wBtB-Kbt08uyDkZXsAb_rXTDQJudHd7Ls0=.bd7bb561-8cde-4f36-a081-adc898d45c4d@github.com>
Message-ID: <wanXQnuLPsv97qWnC6sxaLfgnp1FQoO5-h8LVIFbSYA=.ec88a794-0a53-4dc9-ac8c-3a7464e2e08a@github.com>

On Thu, 20 Mar 2025 14:23:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

This pull request has now been integrated.

Changeset: 997aa176
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/997aa176dbfc3709f8731c10f901334334e606d1
Stats:     7 lines in 2 files changed: 4 ins; 1 del; 2 mod

8351310: Deprecate com.sun.jdi.JDIPermission for removal

Reviewed-by: sspitsyn, cjplummer

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

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

From kevinw at openjdk.org  Tue Mar 25 12:35:19 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 12:35:19 GMT
Subject: RFR: 8351224: Deprecate com.sun.tools.attach.AttachPermission for
 removal
In-Reply-To: <1A0Lh6G3_73k8ZErT3Bs5kPvoipkW6T-Ss2nBAT_0jQ=.81859d22-0485-44d0-bb6b-e3efd025bc46@github.com>
References: <1A0Lh6G3_73k8ZErT3Bs5kPvoipkW6T-Ss2nBAT_0jQ=.81859d22-0485-44d0-bb6b-e3efd025bc46@github.com>
Message-ID: <h7mOLkGoSbrVczs6LC0ETa97XW0Pz3tRPrYFuZIxzUk=.5b51a834-46aa-4ca9-878b-0fb45ce9cf14@github.com>

On Thu, 20 Mar 2025 14:27:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24133#issuecomment-2751106034

From kevinw at openjdk.org  Tue Mar 25 12:35:20 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 12:35:20 GMT
Subject: Integrated: 8351224: Deprecate com.sun.tools.attach.AttachPermission
 for removal
In-Reply-To: <1A0Lh6G3_73k8ZErT3Bs5kPvoipkW6T-Ss2nBAT_0jQ=.81859d22-0485-44d0-bb6b-e3efd025bc46@github.com>
References: <1A0Lh6G3_73k8ZErT3Bs5kPvoipkW6T-Ss2nBAT_0jQ=.81859d22-0485-44d0-bb6b-e3efd025bc46@github.com>
Message-ID: <XpftOwnIt_kRMAgG-SYxmqL8vTv-xk06LlAMYkyyJUE=.e9595445-83d4-4af0-9cc0-b0ec5d954ee3@github.com>

On Thu, 20 Mar 2025 14:27:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Following on from JEP 486 (Permanently Disable the Security Manager), there are Permission classes which are unused. These should be deprecated, for removal in future.

This pull request has now been integrated.

Changeset: 3ac9678e
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ac9678ea1078087f047cb31fb705d94de3f690e
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8351224: Deprecate com.sun.tools.attach.AttachPermission for removal

Reviewed-by: sspitsyn

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

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

From rehn at openjdk.org  Tue Mar 25 14:25:38 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 25 Mar 2025 14:25:38 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user
Message-ID: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>

Hi, for you to consider.

These tests constantly fails in qemu-user.
Either the require host to be same arch or they are very very slow in emulation.
E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
This is the initial set of tests, there are many more, but I need to do some more verification for those.

>From bug:
> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
> We add this uarch to CPU feature string.
> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.

Relevant qemu code:
https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29

Relevant hotspot code:
https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250

Tested that the require only filters out tests in qemu+riscv64.

Thanks!

/Robbin

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

Commit messages:
 - more
 - more
 - native or very long

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

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

From cjplummer at openjdk.org  Tue Mar 25 16:38:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Mar 2025 16:38:13 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <qAG4yJ8EV8Ojlx6lOorPKsgPCNbgS1HQ1Uk0morjHME=.8e48ef98-a945-4ea7-9122-f4659c18982f@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java line 60:

> 58:     // Careful with these values.
> 59:     private static final long MIN_TIME_FOR_PASS = 1;
> 60:     private static final long MAX_TIME_FOR_PASS = Long.MAX_VALUE / 1000;

I think this is still 9,223,372 seconds. Seems it should be lower. It might be best to work in the opposite direction. Decide how many seconds and then multiply that by 1,000,000,000.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2012500672

From lmesnik at openjdk.org  Tue Mar 25 17:55:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 17:55:13 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <fXlvGq7Yu-z0x44-PDWA73n7vugOmA-mfvM4q5ZoNfo=.0fe93530-5889-4cce-805c-6ea148ed255b@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

Generally, changes looks good for me. Please address @plummercj comments.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24186#pullrequestreview-2714674461

From lmesnik at openjdk.org  Tue Mar 25 18:02:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 18:02:13 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <AQjxfsMY9-T0-jjt0stXr7Lexs6Lyz2hKTbgTdkBlV4=.9b18f42f-80c3-4cdd-b9c6-84ead9707d94@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

The only one generic question: doesn't it makes sense to update JMX to retry several times if Windows 2029 returns -1.0 or undefined to make JDK more reliable?
Are tools like JMC/VisualVM suffer from this issue or they make a lot of request to track data and can live with this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2752098518

From lmesnik at openjdk.org  Tue Mar 25 18:06:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 18:06:12 GMT
Subject: RFR: 8352812: remove useless class and function parameter in
 SuspendThread impl
In-Reply-To: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
References: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
Message-ID: <XZDY9vGEZ8H3TO7bPQJDQtAVpG1K32tk0klVtFUxSrg=.84d06532-64af-4472-9d90-5dcafc7d3cf5@github.com>

On Tue, 25 Mar 2025 08:53:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal class JvmtiSuspendControl is transitively used in the SuspendThread implementation is not really needed and is being removed. Also, the suspend_thread function has unused need_safepoint_p parameter which is being removed as well.
> 
> Testing:
>  - TBD: Run mach5 tiers 1-3 to be safe

The fix looks good.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24219#pullrequestreview-2714716556

From stefank at openjdk.org  Tue Mar 25 18:58:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 25 Mar 2025 18:58:08 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
Message-ID: <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>

On Mon, 24 Mar 2025 17:00:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > And isn't this locking scheme exactly what the current code is using? Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.
> 
> What about the case where one thread reserves a range and another thread releases it?
> 
> 1 Thread A reserves range 2 Thread B releases range 3 Thread B tells NMT "range released" 4 Thread A tells NMT "range reserved"
> 
> This would either result in an assert in NMT at step 3 when releasing a range NMT does not know. Or in an incorrectly booked range in step 4 without asserts. Am I making a thinking error somewhere?

In a scenario like that, doesn't Thread A have to communicate somehow that Thread B can now start using and/or releasing that reservation? It sounds like you would have a race condition if you don't have synchronization to hand over the reservation from one thread to another. I would expect that such communication would be be placed after the NMT booking in Thread A.


Thread A:
reserve
lock
NMT booking
unlock
<synchronizing operation (maybe a release_store into a data structure)>

Thread B:
<synchronizing operation (maybe a load_acquire from the same data structure)>
lock
release
NMT booking
unlock


Are there any code that we know of that doesn't fit into a synchronization pattern similar to the above?

I can think of some contrived example where Thread B asks the OS for memory mappings and uses that to ascertain that a pre-determined address has been reserved, and how that could lead to an incorrect booking as you described, but do we really have code like that? If we do, should we really have code like that? Are there some other patterns that I'm missing?

Related to this, I talked to @xmas92 and he mused about swapping the order of the release and NMT release booking as a way to shrink the lock scope for the release operation:


Thread A:
reserve
lock
NMT booking
unlock
<synchronizing operation (maybe a release_store into a data structure)>

Thread B:
<synchronizing operation (maybe a load_acquire from the same data structure)>
lock
NMT booking
unlock
release


As long as we hold the reservation, no other thread can re-reserve the reservation, so Thread B can take its time to first perform the NMT release booking under the lock, and then perform the release without the lock. If another thread (say Thread C) manages to re-reserve the memory, it sounds reasonable that the NMT release booking should have already completed. If we were to try this out, we would have to verify/ensure that the release/reserve pairs perform enough synchronization to make this work. Axel can probably correct me if I mischaracterized what he wrote.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2752240832

From stefank at openjdk.org  Tue Mar 25 19:01:10 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 25 Mar 2025 19:01:10 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <C9OKyQ0atpiaviMrIm7tWHpGoCbO1FXuyX6ieV7eH1g=.55ffcdc9-cdd8-4174-a3ad-fb69f1c78a46@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <C9OKyQ0atpiaviMrIm7tWHpGoCbO1FXuyX6ieV7eH1g=.55ffcdc9-cdd8-4174-a3ad-fb69f1c78a46@github.com>
Message-ID: <xN5agCwMEV5gtsOHWt0e-EfUcxj8NzULC50FE63iWPQ=.e517368d-feaf-4102-b604-78052cc7591d@github.com>

On Mon, 24 Mar 2025 17:11:55 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> Hi stefank, I think you're right about (1.1) (2.1) (2.2) (1.2) being prevented by the current implementation. Is there a reason that the current implementation only does the wider locking for release/uncommit? Maybe (2.1) (1.1) (1.2) (2.2) isn't much of an issue since it's unlikely that another thread would uncommit/release the same base address shortly after it's committed/reserved?

I'm very curious to find out if anyone knows how this could happen without a race condition hand-over from one thread to another. (See my answer to St?fe).

> 
> > Have you seen an issue that this proposed PR intends to solve? If there is such a problem I wonder if there's just a missing lock extension in one of the "release" operations.
> 
> I haven't seen that race in the wild, I just noticed that the memory operations weren't protected and thought that it could be a problem.

OK. Let's see if anyone finds a hole in my arguments given above.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2752247631

From cjplummer at openjdk.org  Tue Mar 25 19:45:17 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Mar 2025 19:45:17 GMT
Subject: RFR: 8352812: remove useless class and function parameter in
 SuspendThread impl
In-Reply-To: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
References: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
Message-ID: <lsOuwvNDgnNafsrCGMu1Cfodu8I-AMpWgvS-AUNZ8vk=.68df013c-3b53-407d-9f1d-3ad6459cdaf0@github.com>

On Tue, 25 Mar 2025 08:53:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal class JvmtiSuspendControl is transitively used in the SuspendThread implementation is not really needed and is being removed. Also, the suspend_thread function has unused need_safepoint_p parameter which is being removed as well.
> 
> Testing:
>  - TBD: Run mach5 tiers 1-3 to be safe

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24219#pullrequestreview-2714992198

From duke at openjdk.org  Tue Mar 25 20:23:20 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 25 Mar 2025 20:23:20 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
Message-ID: <i86m1760OGr-UBnKTSnepy6Ow1h_7UljisvQAi2Gyjk=.424802c8-ebaf-40e2-ac05-b62da2c3fe8b@github.com>

On Tue, 25 Mar 2025 18:55:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> ... swapping the order of the release and NMT release booking as a way to shrink the lock scope for the release operation:
...
As long as we hold the reservation, no other thread can re-reserve the reservation, so Thread B can take its time to first perform the NMT release booking under the lock, and then perform the release without the lock.

Hi @stefank, I think that's true. But if the release/uncommit does not complete successfully we would need to readjust the accounting afterward. To do that we would need to retrieve the original memtag (at least for reserved regions) and potentially need to retrieve the original callsite data (if we're in detailed mode).

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2752423849

From stefank at openjdk.org  Tue Mar 25 20:52:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 25 Mar 2025 20:52:21 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <i86m1760OGr-UBnKTSnepy6Ow1h_7UljisvQAi2Gyjk=.424802c8-ebaf-40e2-ac05-b62da2c3fe8b@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <i86m1760OGr-UBnKTSnepy6Ow1h_7UljisvQAi2Gyjk=.424802c8-ebaf-40e2-ac05-b62da2c3fe8b@github.com>
Message-ID: <fX4AU-gy4u0rMP9ttnpe3HljyRHhrWEr6f_qn0bnnL8=.78d611e3-45e7-4347-a8f9-01d88d30ef8e@github.com>

On Tue, 25 Mar 2025 20:20:55 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> > ... swapping the order of the release and NMT release booking as a way to shrink the lock scope for the release operation:
> > ...
> > As long as we hold the reservation, no other thread can re-reserve the reservation, so Thread B can take its time to first perform the NMT release booking under the lock, and then perform the release without the lock.
> 
> Hi @stefank, I think that's true. But if the release/uncommit does not complete successfully we would need to readjust the accounting afterward. To do that we would need to retrieve the original memtag (at least for reserved regions) and potentially need to retrieve the original callsite data (if we're in detailed mode).

When does a release/uncommit fail? Would that be a JVM bug? What state is the memory in when such a failure happens? Do we even know if the memory is still committed if an uncommit fails?

If I look at the man page for munmap it only fails if you pass in incorrect values, which sounds like a JVM bug to me. I don't understand why we don't treat that as a fatal error *OR* make sure that all call-sites handles that error, which they don't do today.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2752513700

From kevinw at openjdk.org  Tue Mar 25 20:58:07 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 20:58:07 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v3]
In-Reply-To: <AQjxfsMY9-T0-jjt0stXr7Lexs6Lyz2hKTbgTdkBlV4=.9b18f42f-80c3-4cdd-b9c6-84ead9707d94@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
 <AQjxfsMY9-T0-jjt0stXr7Lexs6Lyz2hKTbgTdkBlV4=.9b18f42f-80c3-4cdd-b9c6-84ead9707d94@github.com>
Message-ID: <Nq5aAhmrLllZpuRomhnbmHZpud7KeA2FT-Sbtxa7Z6Q=.10472312-895b-46fa-80aa-918a5b9d0002@github.com>

On Tue, 25 Mar 2025 17:57:56 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The only one generic question: doesn't it makes sense to update JMX to retry several times if Windows 2029 returns -1.0 or undefined to make JDK more reliable? Are tools like JMC/VisualVM suffer from this issue or they make a lot of request to track data and can live with this.

Yes, I was bit worried about adding the overhead of repeating the call, maybe 5 times, with short sleeps, in the MBean CPU monitoring code.  It's been this way "forever", and is documented to return a negative value when info is "not available", so it is still delivering what it promises.  
In our CI it's only Windows Server 2019 10.0 (amd64) where we see a problem.  I don't see actual user reports of it being a problem.  Once the call "works" it seems stable,  so maybe the test is fast to startup and sees the problem.  I think it's better to have the retry on (rare) failure than have the test delay to try and miss the problem, I don't know how reliable that would be without more investigation (which does not seem worthwhile right now).  That may also relate to no reports from JMC/JConsole, but I'm just speculating now. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2752526446

From lmesnik at openjdk.org  Tue Mar 25 21:35:13 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 25 Mar 2025 21:35:13 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v3]
In-Reply-To: <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
Message-ID: <94CgHQiLhyfJHmHpoNNarJhvUK2TQvTVt8LrpNN9Si4=.b40c8b8c-0a40-4775-8fc4-e83184c17bae@github.com>

On Tue, 25 Mar 2025 11:21:28 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter check

That's fine then.

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2752596081

From kevinw at openjdk.org  Tue Mar 25 21:40:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 21:40:17 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v3]
In-Reply-To: <qAG4yJ8EV8Ojlx6lOorPKsgPCNbgS1HQ1Uk0morjHME=.8e48ef98-a945-4ea7-9122-f4659c18982f@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <yiykczTK-bZ1NX-4ATqayHPwMLw0SL9VdFDTj3iKjVk=.a0661397-65e5-4b1d-a8ed-f58f54f9fd82@github.com>
 <qAG4yJ8EV8Ojlx6lOorPKsgPCNbgS1HQ1Uk0morjHME=.8e48ef98-a945-4ea7-9122-f4659c18982f@github.com>
Message-ID: <6mvFHY2u0BQtTIKcGhrINuK49i1hpKSxd_x8DbsXyGA=.879b79b1-7b7b-47d7-9b14-b47cfefe3e14@github.com>

On Tue, 25 Mar 2025 16:35:04 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stricter check
>
> test/jdk/com/sun/management/OperatingSystemMXBean/GetProcessCpuTime.java line 60:
> 
>> 58:     // Careful with these values.
>> 59:     private static final long MIN_TIME_FOR_PASS = 1;
>> 60:     private static final long MAX_TIME_FOR_PASS = Long.MAX_VALUE / 1000;
> 
> I think this is still 9,223,372 seconds. Seems it should be lower. It might be best to work in the opposite direction. Decide how many seconds and then multiply that by 1,000,000,000.

Yes... 
My concern was that 0x7FFFFFFFFFFFFFFF if actually returned, must surely indicate a problem, and the test has been checking if a long is > Long.MAX_VALUE, which can't be useful.  So reducing it even slightly at least give the check some meaning.

I can reduce the value further...
The test obviously avoids guessing what the value should be, to avoid it varying too much one day, and causing a failure.

I've seen the test with -Xcomp, log ns value of 48,580,000,000 but there might be much slower runs out there.

If I use Long.max_value / 10000000 it would have to be about 20 times slower to cause a failure.

Long.max_value / 1000000 =     9,223,372,036,854
Long.max_value / 10000000 =      922,337,203,685
Xcomp example                     48,580,000,000

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24186#discussion_r2012976566

From kevinw at openjdk.org  Tue Mar 25 21:46:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 25 Mar 2025 21:46:26 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v4]
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:

  stricter max time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24186/files
  - new: https://git.openjdk.org/jdk/pull/24186/files/453faf4d..c420e213

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

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

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

From cjplummer at openjdk.org  Wed Mar 26 00:04:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 00:04:45 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
Message-ID: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>

Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

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

Commit messages:
 - get rid of unused breakpoint event code
 - fix more jcheck errors
 - fix jcheck errors
 - Avoid class loading in ThreadGroup.subgroupsAsArray()

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

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

From cjplummer at openjdk.org  Wed Mar 26 00:04:45 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 00:04:45 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <ToyH_Yl7_1JOg2ObjcMfTAX_Qa4P66ftGReKS7llN0U=.8558e1ab-3969-4538-9e63-d474a5445386@github.com>

On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

The reason is because this JDI API eventually ends up with JVMTI doing a java upcall to ThreadGroup.subgroupsAsArray(), which can trigger class loading the first time it is called. Thjis results in a ClassPrepareEvent that the debugger will get, but not process because its event handler thread is blocked on the ThreadGroupReference.groups(), so we have a deadlock.

The workaround is to make ThreadGroupReference.groups() not trigger any class loading. The fix is subtle. Before the fix, the java stack trace at the time of the ClasPrepareEvent looks like:

java.util.Arrays.copyOf(java.lang.Object[], int, java.lang.Class) bci:18 line:3513
java.util.ArrayList.toArray(java.lang.Object[]) bci:21 line:401
java.lang.ThreadGroup.subgroupsAsArray() bci:10 line:751

This is ThreadGroup.subgroupsAsArray:

private ThreadGroup[] subgroupsAsArray() {
    List<ThreadGroup> groups = synchronizedSubgroups();
    return groups.toArray(new ThreadGroup[0]);
}

This is ArrayList.toArray():

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (T[]) Arrays.copyOf(elementData, size, a.getClass());  <--- Line 401
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

And this is Arrays.copyOf():

public static <T,U> T[] copyOf(U[] original, int newLength, Class<? extends T[]> newType) {
    @SuppressWarnings("unchecked")
    T[] copy = ((Object)newType == (Object)Object[].class)
        ? (T[]) new Object[newLength]
        : (T[]) Array.newInstance(newType.getComponentType(), newLength);
    System.arraycopy(original, 0, copy, 0,
                     Math.min(original.length, newLength));
    return copy;
}

Line 3513 is actually the return statement, so this seems incorrect of by a bit. Adding some tracing of ClassPrepareEvents shows that we are currently handling the following:

cbClassPrepare: java.lang.reflect.Array

So it looks like we took the Array.newInstance() path, which triggered class loading of java.lang.reflect.Array. After the fix we never end up in Arrays.copyOf(). Instead ArrayList.toArray() calls System.arraycopy() directly, avoiding any class loading..

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

PR Comment: https://git.openjdk.org/jdk/pull/24236#issuecomment-2752702624

From cjplummer at openjdk.org  Wed Mar 26 00:11:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 00:11:06 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <DfYA3NUB9gtRmvJiakuHr8Lmr22OMDrhFY--SxoMA0E=.6db4ba61-de0f-4300-a4a5-8db3509ca885@github.com>

On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

Sorry, I used the wrong bugID for this PR

Ok, bugID is correct now.

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

PR Comment: https://git.openjdk.org/jdk/pull/24236#issuecomment-2752805402
PR Comment: https://git.openjdk.org/jdk/pull/24236#issuecomment-2752807677

From sspitsyn at openjdk.org  Wed Mar 26 00:19:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Mar 2025 00:19:12 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v4]
In-Reply-To: <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
Message-ID: <J92CRiu2F5qTnQixbl7tddNRSxX3zQyUldjm-aONUss=.1e102c9c-06e6-4ea7-a055-4c8b4a4e7976@github.com>

On Tue, 25 Mar 2025 21:46:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter max time

The fix is a little bit hacky but as a work around should be okay.
LGTM

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24186#pullrequestreview-2715462558

From jpai at openjdk.org  Wed Mar 26 02:00:15 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Mar 2025 02:00:15 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <A_TEJ6Tx-HCOov2SM1W2OR8J73xUCyvCC2fnctZSJ4k=.57e91b80-13f5-4fd5-af4a-4652cb59f05f@github.com>

On Tue, 25 Mar 2025 20:36:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

src/java.base/share/classes/java/lang/ThreadGroup.java line 664:

> 662:     private ThreadGroup[] subgroupsAsArray() {
> 663:         List<ThreadGroup> groups = synchronizedSubgroups();
> 664:         return groups.toArray(new ThreadGroup[groups.size()]);

Hello Chris, would a comment on this line be necessary to prevent future (IDE encouraged [1]) refactoring of this code back to `toArray(new ThreadGroup[0])`?

[1] 
<img width="983" alt="toArray" src="https://github.com/user-attachments/assets/643e66b8-c18a-4a10-8961-2aa3b2869fcc" />

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2013272532

From fyang at openjdk.org  Wed Mar 26 02:24:06 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 26 Mar 2025 02:24:06 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user
In-Reply-To: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
Message-ID: <yzPVXLngMiMIN3kl5tgCVfdEG37yyPGTq4nANIl-zA0=.a868f506-7185-4155-a867-00f94b5faf1b@github.com>

On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, for you to consider.
> 
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
> This is the initial set of tests, there are many more, but I need to do some more verification for those.
> 
> From bug:
>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>> We add this uarch to CPU feature string.
>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
> 
> Relevant qemu code:
> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
> 
> Relevant hotspot code:
> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
> 
> Tested that the require only filters out tests in qemu+riscv64.
> 
> Thanks!
> 
> /Robbin

Hi, This is interesting! But why not use qemu-system instead then? Although a bit slower than qemu-user, this functions well like a real linux system. When testing new riscv features without hardware implementations, I always use qemu-system with a big timeout factor, like: `make test TEST=hotspot:tier1 JTREG="TIMEOUT_FACTOR=24"`. This seems to work on my Xeon Gold 6278C X86 server. It takes about one day or two to build and run `hotspot:tier1`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2753071048

From sspitsyn at openjdk.org  Wed Mar 26 03:12:44 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Mar 2025 03:12:44 GMT
Subject: RFR: 8352812: remove useless class and function parameter in
 SuspendThread impl [v2]
In-Reply-To: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
References: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
Message-ID: <u3NpEn4NNhYeS37ExbAaPaJPbH1WvrVtq9shSQZKM_o=.ade1fd90-ae38-4b90-8a5f-04d1725551a3@github.com>

> The internal class JvmtiSuspendControl is transitively used in the SuspendThread implementation is not really needed and is being removed. Also, the suspend_thread function has unused need_safepoint_p parameter which is being removed as well.
> 
> Testing:
>  - TBD: Run mach5 tiers 1-3 to be safe

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo caused build time error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24219/files
  - new: https://git.openjdk.org/jdk/pull/24219/files/8513e69f..daf1735b

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

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

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

From sspitsyn at openjdk.org  Wed Mar 26 03:44:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Mar 2025 03:44:07 GMT
Subject: RFR: 8352812: remove useless class and function parameter in
 SuspendThread impl [v2]
In-Reply-To: <u3NpEn4NNhYeS37ExbAaPaJPbH1WvrVtq9shSQZKM_o=.ade1fd90-ae38-4b90-8a5f-04d1725551a3@github.com>
References: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
 <u3NpEn4NNhYeS37ExbAaPaJPbH1WvrVtq9shSQZKM_o=.ade1fd90-ae38-4b90-8a5f-04d1725551a3@github.com>
Message-ID: <AD9syAOXzLd3ZEbb-5tHJI_p7UgXAH0vPnyuvdh8CTE=.39d46e45-29da-4b8b-a960-111672c178f9@github.com>

On Wed, 26 Mar 2025 03:12:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal class JvmtiSuspendControl is transitively used in the SuspendThread implementation is not really needed and is being removed. Also, the suspend_thread function has unused need_safepoint_p parameter which is being removed as well.
>> 
>> Testing:
>>  - TBD: Run mach5 tiers 1-3 to be safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo caused build time error

Leonid and Chris, thank you for review!
I've just fixed a typo caused build failures, so a re-review will be needed. Sorry for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/24219#issuecomment-2753162234

From lmesnik at openjdk.org  Wed Mar 26 05:35:22 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 26 Mar 2025 05:35:22 GMT
Subject: RFR: 8352812: remove useless class and function parameter in
 SuspendThread impl [v2]
In-Reply-To: <u3NpEn4NNhYeS37ExbAaPaJPbH1WvrVtq9shSQZKM_o=.ade1fd90-ae38-4b90-8a5f-04d1725551a3@github.com>
References: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
 <u3NpEn4NNhYeS37ExbAaPaJPbH1WvrVtq9shSQZKM_o=.ade1fd90-ae38-4b90-8a5f-04d1725551a3@github.com>
Message-ID: <Xaq5IrGIbth3pC4ipB4jjpDfiub7Kr2h29bdQA9Nw4M=.fd0c8051-05ba-49cd-947b-29495ee104b3@github.com>

On Wed, 26 Mar 2025 03:12:44 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The internal class JvmtiSuspendControl is transitively used in the SuspendThread implementation is not really needed and is being removed. Also, the suspend_thread function has unused need_safepoint_p parameter which is being removed as well.
>> 
>> Testing:
>>  - TBD: Run mach5 tiers 1-3 to be safe
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo caused build time error

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24219#pullrequestreview-2715946424

From rehn at openjdk.org  Wed Mar 26 06:24:14 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 26 Mar 2025 06:24:14 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user
In-Reply-To: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
Message-ID: <WhB-9-MqjOzSCRvjhORiCgBfkaRzSz-fT-cWsjOoHgA=.6222c4b5-d179-40e3-a5ca-ded287a0b4dc@github.com>

On Tue, 25 Mar 2025 14:19:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, for you to consider.
> 
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
> This is the initial set of tests, there are many more, but I need to do some more verification for those.
> 
> From bug:
>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>> We add this uarch to CPU feature string.
>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
> 
> Relevant qemu code:
> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
> 
> Relevant hotspot code:
> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
> 
> Tested that the require only filters out tests in qemu+riscv64.
> 
> Thanks!
> 
> /Robbin

Yes, it's much solver as you can't use a compile jdk.
Note that is not a full tier1, "make test-tier1"
Which means you have a day or two more for a full tier1.

There are plenty of test in the jdk which stress or correctness test runtime/compiler, e.g.:
test/jdk/java/lang/Thread/virtual/MonitorWaitNotify.java
test/jdk/java/lang/Float/Binary16Conversion.java

`make test-tier1 CONF=linux-riscv64-server-fastdebug JTREG="OPTIONS=-e:QEMU_LD_PREFIX=/usr/riscv64-linux-gnu/;JAVA_OPTIONS=;RETAIN=all" JDK_FOR_COMPILE=/home/rehn/source/jdk/vanilla/build/linux-x86_64-server-release/images/jdk JTREG_TIMEOUT_FACTOR=20`

One issue with high timeout factor is that make+jtreg only can parallelize tests in the same directory.
Which means you often end up with just waiting for one test to complete before anything else can happen.

Hotspot tier1 takes around 8h with timeout factor 20 for me in qemu-user, cpu = max, but tests still timeout.
Even when running JOBS=1 some timeout, at least on cpu = max.
Hence this enhancement :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2753357500

From kevinw at openjdk.org  Wed Mar 26 09:06:16 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Mar 2025 09:06:16 GMT
Subject: RFR: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently [v4]
In-Reply-To: <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
 <IvP45zVcYgD66kXFSOQTwqUMBJcp2IGvj0zmhHEfWsg=.e8925925-7988-4602-950f-c855a9b117f4@github.com>
Message-ID: <FNkizekIQW5UV2FDF2Jv_FS9PT7M8bbOhQaEPX2kb5Y=.56c7b03d-3b78-4334-a1dd-8fe799c10c69@github.com>

On Tue, 25 Mar 2025 21:46:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
>> 
>> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
>> 
>> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
>> 
>> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stricter max time

Thanks for all the reviews and comments.

The timing check in GetSystemCpuLoad.java is a little hacky.  That test has never claimed to try and test that the cpu time is "correct", but now it will at least test the time measured is not crazy.  If I got the definition of "crazy" wrong, will be back here...

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

PR Comment: https://git.openjdk.org/jdk/pull/24186#issuecomment-2753660969

From kevinw at openjdk.org  Wed Mar 26 09:06:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 26 Mar 2025 09:06:17 GMT
Subject: Integrated: 8351002: com/sun/management/OperatingSystemMXBean cpuLoad
 tests fail intermittently
In-Reply-To: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
References: <5V7PbeHi-HQtZDvaRhICuwy0b-sMaBd0xx8Zgqfz0bA=.b32c4b44-9969-4a22-b6d9-af4c0736a0c3@github.com>
Message-ID: <ZryRcJH787BV0FDbgYLXkUf37i7RFn37xp9VZwnlrVg=.ea8144d9-0c42-42bf-ae53-a04561cd4569@github.com>

On Mon, 24 Mar 2025 10:13:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> These tests have always silently permitted a -1 return value from OperatingSystemMXBean CPU time methods.
> 
> They need to be stricter, but occasionally Windows 2019 returns a -1 for the first few calls of these methods.  This seems to be a Windows 2019 bug or peculiarity.  Other Windows versions are not affected.
> 
> GetProcessCpuLoad.java and GetSystemCpuLoad.java need to fail only if the CPU time calls continually return -1.  They should permit -1 values, as long as subsequently a value in the valid range is read.
> 
> The GetProcessCpuTime test also needs to retry enough times to expect no -1 values, and not just skip.  While updating this test: it has a maximum expected value of Long.MAX_VALUE, which it may as well reduce to something that does not look like a binary "all ones except for the high bit" value (without creating an ongoing game where we keep increasing the value to avoid failures in slow runs).

This pull request has now been integrated.

Changeset: eb6e8288
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb6e8288c628577ce557266773ffebdf0bbe853a
Stats:     71 lines in 4 files changed: 51 ins; 6 del; 14 mod

8351002: com/sun/management/OperatingSystemMXBean cpuLoad tests fail intermittently

Reviewed-by: sspitsyn, lmesnik

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

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

From alanb at openjdk.org  Wed Mar 26 10:23:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Mar 2025 10:23:13 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user
In-Reply-To: <WhB-9-MqjOzSCRvjhORiCgBfkaRzSz-fT-cWsjOoHgA=.6222c4b5-d179-40e3-a5ca-ded287a0b4dc@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <WhB-9-MqjOzSCRvjhORiCgBfkaRzSz-fT-cWsjOoHgA=.6222c4b5-d179-40e3-a5ca-ded287a0b4dc@github.com>
Message-ID: <IPvCUYMCjlOkoA4_zLd3yctQ0X4_wUIdYl3WJnPj4Gk=.6a797a20-2e87-49fe-b4a1-6ffe0fae2caa@github.com>

On Wed, 26 Mar 2025 06:21:31 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> One issue with high timeout factor is that make+jtreg only can parallelize tests in the same directory. Which means you often end up with just waiting for one test to complete before anything else can happen.

jtreg doesn't require tests that run concurrently with others to be in the same directory. The inverse, where exclusiveAccess.dirs prevents tests in a directory/tree from running at the same time as other tests in that directory/tree also doesn't prevent tests in other locations from executing concurrently.

Given the execution times, I wonder if you've looked at using the finer grain test groups and splitting the execution across a number of machines. Yes, it means combing results but I assume you'll this for high tiers anyway as the execution time goes up significantly beyond tier1.

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2753896771

From rehn at openjdk.org  Wed Mar 26 12:17:08 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 26 Mar 2025 12:17:08 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user
In-Reply-To: <IPvCUYMCjlOkoA4_zLd3yctQ0X4_wUIdYl3WJnPj4Gk=.6a797a20-2e87-49fe-b4a1-6ffe0fae2caa@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <WhB-9-MqjOzSCRvjhORiCgBfkaRzSz-fT-cWsjOoHgA=.6222c4b5-d179-40e3-a5ca-ded287a0b4dc@github.com>
 <IPvCUYMCjlOkoA4_zLd3yctQ0X4_wUIdYl3WJnPj4Gk=.6a797a20-2e87-49fe-b4a1-6ffe0fae2caa@github.com>
Message-ID: <f9U7SAQ8wEjSfpWGfHC0r46CNCvHujLWXg0AzLqb7fg=.af6e9258-61c8-4f31-8466-8b7dbbf3e60f@github.com>

On Wed, 26 Mar 2025 10:20:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > One issue with high timeout factor is that make+jtreg only can parallelize tests in the same directory. Which means you often end up with just waiting for one test to complete before anything else can happen.
> 
> jtreg doesn't require tests that run concurrently with others to be in the same directory. The inverse, where exclusiveAccess.dirs prevents tests in a directory/tree from running at the same time as other tests in that directory/tree also doesn't prevent tests in other locations from executing concurrently.
> 

Sorry, I didn't mean top directory. I meant 'test root dir'/test sub groups (as they usually maps).
I can't force the issue.. it seems to work fine...
But plenty of times the machine have been running just one test and that timeouts it starts a whole bunch of new tests from another test group. Is this recently fixed, or what may be the issue?

E.g.

+robbin = \
+  compiler/c2/irTests \
+  runtime/handshake

It runs tests from both groups in parallel, which is not what I have been seeing?

> Given the execution times, I wonder if you've looked at using the finer grain test groups and splitting the execution across a number of machines. Yes, it means combing results but I assume you'll this for high tiers anyway as the execution time goes up significantly beyond tier1.

Running on my workstation with qemu-user or a small rv64 board there is around 50x time vs x86 for me.
It helps, but requires a bunch of machines.

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2754202998

From duke at openjdk.org  Wed Mar 26 14:19:17 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 26 Mar 2025 14:19:17 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
Message-ID: <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>

On Tue, 25 Mar 2025 18:55:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Are there any code that we know of that doesn't fit into a synchronization pattern similar to the above?
> I can think of some contrived example where Thread B asks the OS for memory mappings and uses that to ascertain that a pre-determined address has been reserved, and how that could lead to an incorrect booking as you described, but do we really have code like that? 

>From what I can tell, it doesn't look like that's happening anywhere, someone else may know better though.  Similarly, for uncommit, the base address must be passed over from somewhere else in the JVM so relying on some external synchonization seems reasonable here too.  If this problem scenario is not present in the current code and it's not expected it to become a possiblity in the future, then I suppose there's no reason to guard against it. Maybe just a comment explaining the reasoning is good enough (and a warning not to use such patterns). 

-----------

> When does a release/uncommit fail? Would that be a JVM bug? 

On Windows, VirtualFree also looks like it only fails if an invalid set of arguments are passed. So if os::pd_release fails it's probably a JVM bug. Uncommit uses mmap, which could fail for a larger variety of reasons. Some reasons are out of control of the JVM. For example: "The number of mapped regions would exceed an implementation-defined limit (per process or per system)." See [here](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp#L191)

> What state is the memory in when such a failure happens? Do we even know if the memory is still committed if an uncommit fails?

If release/uncommit fails, then it would be hard to know what state the target memory is in. If the arguments are invalid (bad base address), the target region may not even be allocated. Or, in the case of uncommit, if the base address is not aligned, maybe the target committed region does indeed exist but the uncommit still fails. So it would be hard to determine how to readjust the NMT accounting afterward.

> I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.

I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled by most places in the caller, release failure seems mostly not.  If we expect that release/uncommit could sometimes fail for valid reasons, then we cannot fail fatally in the os:: functions. Since, at least for uncommit, we could reasonably fail without it being a JVM bug, I think we shouldn't fatally crash when that happens.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2754589497

From stefank at openjdk.org  Wed Mar 26 16:07:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 26 Mar 2025 16:07:08 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
Message-ID: <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>

On Wed, 26 Mar 2025 14:16:06 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> > Are there any code that we know of that doesn't fit into a synchronization pattern similar to the above?
> > I can think of some contrived example where Thread B asks the OS for memory mappings and uses that to ascertain that a pre-determined address has been reserved, and how that could lead to an incorrect booking as you described, but do we really have code like that?
> 
> From what I can tell, it doesn't look like that's happening anywhere, someone else may know better though. Similarly, for uncommit, the base address must be passed over from somewhere else in the JVM so relying on some external synchonization seems reasonable here too. If this problem scenario is not present in the current code and it's not expected it to become a possiblity in the future, then I suppose there's no reason to guard against it. Maybe just a comment explaining the reasoning is good enough (and a warning not to use such patterns).
> 
> > When does a release/uncommit fail? Would that be a JVM bug?
> 
> On Windows, VirtualFree also looks like it only fails if an invalid set of arguments are passed. So if os::pd_release fails it's probably a JVM bug. Uncommit uses mmap, which could fail for a larger variety of reasons. Some reasons are out of control of the JVM. For example: "The number of mapped regions would exceed an implementation-defined limit (per process or per system)." See [here](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp#L191)

Right. And that failure is fatal, so there should be no need to fix any NMT bookkeeping for that.

> 
> > What state is the memory in when such a failure happens? Do we even know if the memory is still committed if an uncommit fails?
> 
> If release/uncommit fails, then it would be hard to know what state the target memory is in. If the arguments are invalid (bad base address), the target region may not even be allocated. Or, in the case of uncommit, if the base address is not aligned, maybe the target committed region does indeed exist but the uncommit still fails. So it would be hard to determine how to readjust the NMT accounting afterward.

Agreed. And this would be a pre-existing problem already. If a release/uncommit fails, then we have the similar issues for that as well.

> 
> > I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.
> 
> I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.

I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2754953604

From stuefe at openjdk.org  Wed Mar 26 16:23:07 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Mar 2025 16:23:07 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <xN5agCwMEV5gtsOHWt0e-EfUcxj8NzULC50FE63iWPQ=.e517368d-feaf-4102-b604-78052cc7591d@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <C9OKyQ0atpiaviMrIm7tWHpGoCbO1FXuyX6ieV7eH1g=.55ffcdc9-cdd8-4174-a3ad-fb69f1c78a46@github.com>
 <xN5agCwMEV5gtsOHWt0e-EfUcxj8NzULC50FE63iWPQ=.e517368d-feaf-4102-b604-78052cc7591d@github.com>
Message-ID: <d9xMcKtG4oD07a-zm-fk19eyWqYuwkwLN4wzQHWzrhU=.1b4c34b6-666f-4775-b1c3-94d9e03e0f08@github.com>

On Tue, 25 Mar 2025 18:58:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > Hi stefank, I think you're right about (1.1) (2.1) (2.2) (1.2) being prevented by the current implementation. Is there a reason that the current implementation only does the wider locking for release/uncommit? Maybe (2.1) (1.1) (1.2) (2.2) isn't much of an issue since it's unlikely that another thread would uncommit/release the same base address shortly after it's committed/reserved?
> 
> I'm very curious to find out if anyone knows how this could happen without a race condition hand-over from one thread to another. (See my answer to St?fe).

Stefan, your analysis sounds reasonable. Don't see a hole. The original issue was from me I think, but I've never seen that variant in real life.

So, I am fine with leaving that scenario out.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2754989908

From stuefe at openjdk.org  Wed Mar 26 16:23:08 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 26 Mar 2025 16:23:08 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
Message-ID: <1S9u0e21AfElb6hNR-rLXa7JIhyUBE35ePRt1d4vhfs=.639232d7-aa07-4ac2-96b2-a2a5414c0377@github.com>

On Wed, 26 Mar 2025 16:05:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > 
> > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> 
> I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?

I second @stefank here.

Uncommit can fail, ironically, with an ENOMEM : if the uncommit punches a hole into a committed region, this would cause a new new VMA on the kernel-side. This may fail if we run against the limit for VMAs. Forgot what it was, some sysconf setting. All of this is Linux specific, though.

I don't think this should be unconditionally a fatal error. Since the allocator (whatever it is) can decide to re-commit the region later, and thus "self-heal" itself.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2754997791

From cjplummer at openjdk.org  Wed Mar 26 16:28:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 16:28:12 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM
In-Reply-To: <YnlVEB01NzI3CF3NWkHqUqSgSVj1Jzcb3pMUcdc0_m8=.6370160b-1964-4de2-845f-0aa840322c4f@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <A_TEJ6Tx-HCOov2SM1W2OR8J73xUCyvCC2fnctZSJ4k=.57e91b80-13f5-4fd5-af4a-4652cb59f05f@github.com>
 <YnlVEB01NzI3CF3NWkHqUqSgSVj1Jzcb3pMUcdc0_m8=.6370160b-1964-4de2-845f-0aa840322c4f@github.com>
Message-ID: <GtgFw-9Z7yG6a0gMVoPZz3zM7d6g7o-mtSt-yod49u8=.6339f8ba-92ef-4e06-9271-9cac2b5ed087@github.com>

On Wed, 26 Mar 2025 09:31:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ThreadGroup.java line 664:
>> 
>>> 662:     private ThreadGroup[] subgroupsAsArray() {
>>> 663:         List<ThreadGroup> groups = synchronizedSubgroups();
>>> 664:         return groups.toArray(new ThreadGroup[groups.size()]);
>> 
>> Hello Chris, would a comment on this line be necessary to prevent future (IDE encouraged [1]) refactoring of this code back to `toArray(new ThreadGroup[0])`?
>> 
>> [1] 
>> <img width="983" alt="toArray" src="https://github.com/user-attachments/assets/643e66b8-c18a-4a10-8961-2aa3b2869fcc" />
>
> What would you think about using the simple code + loop from the JBS comment? That would remove any discussion about toArray and any concerns that it would load classes.

Regarding adding a comment, I wasn't too sure what the comment should say because once you start down that path, it's hard to not end up with too much detail, and then things just get very wordy. Since we have a test that will fail if this is ever modified to cause classloading again, at least that should help prevent undoing this fix. However, the one downside of the test is that I can only get it to fail with non-debug builds, so it may not be caught early.

Regarding using the loop, that's probably a more bullet proof option, although there is still no guarantee that someday someone won't look at it and say "I can just use toArray() here". There's probably no escaping an AI code cleaning bot coming to that conclusion sometime in the near future. Then we're back to adding a comment to make sure it isn't changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014554610

From jpai at openjdk.org  Wed Mar 26 16:43:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Mar 2025 16:43:31 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM
In-Reply-To: <GtgFw-9Z7yG6a0gMVoPZz3zM7d6g7o-mtSt-yod49u8=.6339f8ba-92ef-4e06-9271-9cac2b5ed087@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <A_TEJ6Tx-HCOov2SM1W2OR8J73xUCyvCC2fnctZSJ4k=.57e91b80-13f5-4fd5-af4a-4652cb59f05f@github.com>
 <YnlVEB01NzI3CF3NWkHqUqSgSVj1Jzcb3pMUcdc0_m8=.6370160b-1964-4de2-845f-0aa840322c4f@github.com>
 <GtgFw-9Z7yG6a0gMVoPZz3zM7d6g7o-mtSt-yod49u8=.6339f8ba-92ef-4e06-9271-9cac2b5ed087@github.com>
Message-ID: <XLJeuUGZl3sKlC99yBEw_mWTc_F1xQ5HKpOAj_sq9ZI=.a4f312f5-72c8-463b-ad5d-da7b8a4ccb5b@github.com>

On Wed, 26 Mar 2025 16:25:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> What would you think about using the simple code + loop from the JBS comment? That would remove any discussion about toArray and any concerns that it would load classes.
>
> Regarding adding a comment, I wasn't too sure what the comment should say because once you start down that path, it's hard to not end up with too much detail, and then things just get very wordy. Since we have a test that will fail if this is ever modified to cause classloading again, at least that should help prevent undoing this fix. However, the one downside of the test is that I can only get it to fail with non-debug builds, so it may not be caught early.
> 
> Regarding using the loop, that's probably a more bullet proof option, although there is still no guarantee that someday someone won't look at it and say "I can just use toArray() here". There's probably no escaping an AI code cleaning bot coming to that conclusion sometime in the near future. Then we're back to adding a comment to make sure it isn't changed.

I just noticed that this `subgroupsAsArray()` private method is only used by JVMTI and a comment exists about that on that method:


/**
 * Returns a snapshot of the subgroups as an array, used by JVMTI.
 */

So, irrespective of what solution we choose, perhaps we could add another brief sentence to that comment, something like the following?


/**
 * Returns a snapshot of the subgroups as an array, used by JVMTI.
 * Care should be taken not to trigger any classloading in this method.
 */

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014580285

From stefank at openjdk.org  Wed Mar 26 16:46:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 26 Mar 2025 16:46:08 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <1S9u0e21AfElb6hNR-rLXa7JIhyUBE35ePRt1d4vhfs=.639232d7-aa07-4ac2-96b2-a2a5414c0377@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
 <1S9u0e21AfElb6hNR-rLXa7JIhyUBE35ePRt1d4vhfs=.639232d7-aa07-4ac2-96b2-a2a5414c0377@github.com>
Message-ID: <n-KfQHeMAztr7axw_qC-Ac92K_Nx1VOqeVBcciKVWYw=.41d279f0-4b91-4076-aaaa-5460fc4c88d3@github.com>

On Wed, 26 Mar 2025 16:19:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> > 
> > 
> > I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?
> 
> I second @stefank here.
> 
> Uncommit can fail, ironically, with an ENOMEM : if the uncommit punches a hole into a committed region, this would cause a new new VMA on the kernel-side. This may fail if we run against the limit for VMAs. Forgot what it was, some sysconf setting. All of this is Linux specific, though.

This happens when we hit the /proc/sys/vm/max_map_count limit, and this immediately crashes the JVM.

> 
> I don't think this should be unconditionally a fatal error. Since the allocator (whatever it is) can decide to re-commit the region later, and thus "self-heal" itself.

Is this referring to failures when we hit the max_map_count limit? I'm not convinced that you can recover from that without immediately hitting the same issue somewhere else in the code.

Or maybe you are thinking about some of the other reasons for the uncommit to fail?

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2755066544

From cjplummer at openjdk.org  Wed Mar 26 18:22:00 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 18:22:00 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v2]
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <ww54kk5EamjI53bXGlmiOw7xjVlAqJTA_HVH6zeVRkI=.e911d461-0b08-4652-914f-a3adb267951e@github.com>

> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Use explicit array copying code. Better comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24236/files
  - new: https://git.openjdk.org/jdk/pull/24236/files/18a255c7..3bc43a21

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

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

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

From cjplummer at openjdk.org  Wed Mar 26 18:25:19 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 18:25:19 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v2]
In-Reply-To: <XLJeuUGZl3sKlC99yBEw_mWTc_F1xQ5HKpOAj_sq9ZI=.a4f312f5-72c8-463b-ad5d-da7b8a4ccb5b@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <A_TEJ6Tx-HCOov2SM1W2OR8J73xUCyvCC2fnctZSJ4k=.57e91b80-13f5-4fd5-af4a-4652cb59f05f@github.com>
 <YnlVEB01NzI3CF3NWkHqUqSgSVj1Jzcb3pMUcdc0_m8=.6370160b-1964-4de2-845f-0aa840322c4f@github.com>
 <GtgFw-9Z7yG6a0gMVoPZz3zM7d6g7o-mtSt-yod49u8=.6339f8ba-92ef-4e06-9271-9cac2b5ed087@github.com>
 <XLJeuUGZl3sKlC99yBEw_mWTc_F1xQ5HKpOAj_sq9ZI=.a4f312f5-72c8-463b-ad5d-da7b8a4ccb5b@github.com>
Message-ID: <hYnuOAlyTeBaxixwqU1aUJYm27naUyNPryOyI-jY99A=.9579cb32-e9d1-42ce-9dbd-ed7e887339a6@github.com>

On Wed, 26 Mar 2025 16:39:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Regarding adding a comment, I wasn't too sure what the comment should say because once you start down that path, it's hard to not end up with too much detail, and then things just get very wordy. Since we have a test that will fail if this is ever modified to cause classloading again, at least that should help prevent undoing this fix. However, the one downside of the test is that I can only get it to fail with non-debug builds, so it may not be caught early.
>> 
>> Regarding using the loop, that's probably a more bullet proof option, although there is still no guarantee that someday someone won't look at it and say "I can just use toArray() here". There's probably no escaping an AI code cleaning bot coming to that conclusion sometime in the near future. Then we're back to adding a comment to make sure it isn't changed.
>
> I just noticed that this `subgroupsAsArray()` private method is only used by JVMTI and a comment exists about that on that method:
> 
> 
> /**
>  * Returns a snapshot of the subgroups as an array, used by JVMTI.
>  */
> 
> So, irrespective of what solution we choose, perhaps we could add another brief sentence to that comment, something like the following?
> 
> 
> /**
>  * Returns a snapshot of the subgroups as an array, used by JVMTI.
>  * Care should be taken not to trigger any classloading in this method.
>  */

I switched to the code that does the array copy inline rather than rely on toArray(). I also added a comment. I intentionally kept is short and simple. I was tempted to say something about toArray(), reference the CR, mention JDI and the debug agent, etc, but that's heading down the "too wordy" path that I wanted to avoid. Readers can "git blame" to find out why it was done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014778518

From duke at openjdk.org  Wed Mar 26 19:00:17 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 26 Mar 2025 19:00:17 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
Message-ID: <kWSNHJBVi5HMrIpSrgj1W2yy4SqVdvvWLTkR35xILgI=.fd68072f-2fed-4273-83a2-2bbe405b6f79@github.com>

On Wed, 26 Mar 2025 16:05:00 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>>> What state is the memory in when such a failure happens? Do we even know if the memory is still committed if an uncommit fails?
> >
>> If release/uncommit fails, then it would be hard to know what state the target memory is in. If the arguments are invalid (bad base address), the target region may not even be allocated. Or, in the case of uncommit, if the base address is not aligned, maybe the target committed region does indeed exist but the uncommit still fails. So it would be hard to determine how to readjust the NMT accounting afterward.
> 
> Agreed. And this would be a pre-existing problem already. If a release/uncommit fails, then we have the similar issues for that as well.

Hi @stefank, Are you referring to the difficulty in determining the original allocation as being the pre-existing problem? I think that only becomes an issue if we decide to swap the order of NMT booking and the memory release/uncommit (assuming we don't just fail fatally). Since we don't need to readjust currently, if there's a failure we can just leave everything as it is.

>>> I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.
> >
>> I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> 
> I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?

[`VirtualSpace::shrink_by`](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/virtualspace.cpp#L373) allows uncommit to fail without crashing. I'm not certain of the intention behind that. But it seems like it's because shrinking is an optimization and not always critical  that it be done immediately. [[1](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/gc/serial/tenuredGeneration.cpp#L258)]

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2755468073

From cjplummer at openjdk.org  Wed Mar 26 19:17:44 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 19:17:44 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v3]
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <Cyckpd3J6bhS3QKwn0R7DTr7-68Gmc0nfVPney1dXCc=.eb1d9dbc-72c1-4d22-8187-8a2e74d54cbb@github.com>

> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  minor comment fix.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24236/files
  - new: https://git.openjdk.org/jdk/pull/24236/files/3bc43a21..ea44034c

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

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

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

From alanb at openjdk.org  Wed Mar 26 19:17:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 26 Mar 2025 19:17:45 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v2]
In-Reply-To: <ww54kk5EamjI53bXGlmiOw7xjVlAqJTA_HVH6zeVRkI=.e911d461-0b08-4652-914f-a3adb267951e@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <ww54kk5EamjI53bXGlmiOw7xjVlAqJTA_HVH6zeVRkI=.e911d461-0b08-4652-914f-a3adb267951e@github.com>
Message-ID: <YgPXfxzjCv8Tculuv7FdCb-DEXTwC01xtEBQZjusrcc=.0b3b0413-8bee-46fe-86b9-f5b97e0ae241@github.com>

On Wed, 26 Mar 2025 18:22:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use explicit array copying code. Better comment.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/lang/ThreadGroup.java line 661:

> 659:     /**
> 660:      * Returns a snapshot of the subgroups as an array, used by JVMTI.
> 661:      * WARNING: Make sure this API does not trigger any class loading.

Might be better to say "method" rather than "API" as this is all internal.

test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 55:

> 53: public class EarlyThreadGroupChildrenTest extends TestScaffold {
> 54:     ClassType targetClass;
> 55:     ThreadReference mainThread;

Are these used? Maybe copied over from another test?

test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 83:

> 81:     public void classPrepared(ClassPrepareEvent event) {
> 82:         try {
> 83:             ++classPreparedCount;

It's a long standing since I looked at at test based on TestScaffold. Would I be correct to say that it creates an event  handler thread to remove events from the event queue and dispatch them to the registered listeners? Only asking as it's not immediately clear if the increment of the event count is correct. I think TestScaffold uses one thread but would need to dig into the test infra to be sure.

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

PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2718340853
PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014828734
PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014831539
PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014843667

From sspitsyn at openjdk.org  Wed Mar 26 19:48:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 26 Mar 2025 19:48:20 GMT
Subject: Integrated: 8352812: remove useless class and function parameter in
 SuspendThread impl
In-Reply-To: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
References: <U8OYOG2QqfagoAnqoEFKnKUUiIA-Lj9-S4myNcQT9Oo=.cc1d1d87-315a-4880-8a3c-35b184b6a1b0@github.com>
Message-ID: <I4krgA8L-JsZ_sbDIWni2hOvAJHLWGE2yt7w-8nVNp0=.8d81ab33-0918-443b-816c-4012388bf810@github.com>

On Tue, 25 Mar 2025 08:53:48 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The internal class JvmtiSuspendControl is transitively used in the SuspendThread implementation is not really needed and is being removed. Also, the suspend_thread function has unused need_safepoint_p parameter which is being removed as well.
> 
> Testing:
>  - TBD: Run mach5 tiers 1-3 to be safe

This pull request has now been integrated.

Changeset: 441bd126
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/441bd1265650dc865897d5cb6a673edb89dd5cee
Stats:     68 lines in 5 files changed: 0 ins; 58 del; 10 mod

8352812: remove useless class and function parameter in SuspendThread impl

Reviewed-by: lmesnik, cjplummer

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

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

From stefank at openjdk.org  Wed Mar 26 20:21:17 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 26 Mar 2025 20:21:17 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <kWSNHJBVi5HMrIpSrgj1W2yy4SqVdvvWLTkR35xILgI=.fd68072f-2fed-4273-83a2-2bbe405b6f79@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
 <kWSNHJBVi5HMrIpSrgj1W2yy4SqVdvvWLTkR35xILgI=.fd68072f-2fed-4273-83a2-2bbe405b6f79@github.com>
Message-ID: <5wBQqxybptneJjhR5usfrqg3PJ7G2PB_sDjUkb4BObM=.fe04a403-64ad-4dc5-b793-b48da01acfd4@github.com>

On Wed, 26 Mar 2025 18:57:51 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> > > > What state is the memory in when such a failure happens? Do we even know if the memory is still committed if an uncommit fails?
> > > 
> > > 
> > > If release/uncommit fails, then it would be hard to know what state the target memory is in. If the arguments are invalid (bad base address), the target region may not even be allocated. Or, in the case of uncommit, if the base address is not aligned, maybe the target committed region does indeed exist but the uncommit still fails. So it would be hard to determine how to readjust the NMT accounting afterward.
> > 
> > 
> > Agreed. And this would be a pre-existing problem already. If a release/uncommit fails, then we have the similar issues for that as well.
> 
> Hi @stefank, Are you referring to the difficulty in determining the original allocation as being the pre-existing problem? I think that only becomes an issue if we decide to swap the order of NMT booking and the memory release/uncommit (assuming we don't just fail fatally). Since we don't need to readjust currently, if there's a failure we can just leave everything as it is.

My thinking is that if there is a failure you don't know what state the OS left the memory in. So, you don't know whether the memory was in fact unmapped as requested, or if it was left intact, or even something in-between. So, if you don't do the matching NMT bookkeeping there will be a mismatch between the state of the memory and what has been bookkeeped in NMT.

> 
> > > > I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.
> > > 
> > > 
> > > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> > 
> > 
> > I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?
> 
> [`VirtualSpace::shrink_by`](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/virtualspace.cpp#L373) allows uncommit to fail without crashing. I'm not certain of the intention behind that. But it seems like it's because shrinking is an optimization and not always critical that it be done immediately. [[1](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/gc/serial/tenuredGeneration.cpp#L258)]

The above example shows code that assumes that it is OK to fail uncommitting and continuing. I'm trying to figure it that assumption is true. So, what I meant was that I was looking for a concrete example of a failure mode of uncommit that would be an acceptable (safe) failure to continue executing from. That is, a valid failure that don't mess up the memory in an unpredictable/unknowable way.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2755656985

From cjplummer at openjdk.org  Wed Mar 26 20:23:11 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 20:23:11 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v2]
In-Reply-To: <YgPXfxzjCv8Tculuv7FdCb-DEXTwC01xtEBQZjusrcc=.0b3b0413-8bee-46fe-86b9-f5b97e0ae241@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <ww54kk5EamjI53bXGlmiOw7xjVlAqJTA_HVH6zeVRkI=.e911d461-0b08-4652-914f-a3adb267951e@github.com>
 <YgPXfxzjCv8Tculuv7FdCb-DEXTwC01xtEBQZjusrcc=.0b3b0413-8bee-46fe-86b9-f5b97e0ae241@github.com>
Message-ID: <q5FAFcxJPqDdNdxlj4LWR8UKWV5vDFhxvJyXbdzYKxc=.51b635dd-4c5a-4cf8-9f0b-5408a66fd547@github.com>

On Wed, 26 Mar 2025 19:01:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use explicit array copying code. Better comment.
>
> test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 55:
> 
>> 53: public class EarlyThreadGroupChildrenTest extends TestScaffold {
>> 54:     ClassType targetClass;
>> 55:     ThreadReference mainThread;
> 
> Are these used? Maybe copied over from another test?

Yes, copied from another test. I'll remove them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014943008

From cjplummer at openjdk.org  Wed Mar 26 20:40:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 20:40:09 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v2]
In-Reply-To: <YgPXfxzjCv8Tculuv7FdCb-DEXTwC01xtEBQZjusrcc=.0b3b0413-8bee-46fe-86b9-f5b97e0ae241@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <ww54kk5EamjI53bXGlmiOw7xjVlAqJTA_HVH6zeVRkI=.e911d461-0b08-4652-914f-a3adb267951e@github.com>
 <YgPXfxzjCv8Tculuv7FdCb-DEXTwC01xtEBQZjusrcc=.0b3b0413-8bee-46fe-86b9-f5b97e0ae241@github.com>
Message-ID: <luJtnjespQIO1FAT69i6CcEp-po0yuWL0H4Ya2Ip2IQ=.2838b808-4847-4811-9053-2d1201e993f6@github.com>

On Wed, 26 Mar 2025 19:11:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use explicit array copying code. Better comment.
>
> test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 83:
> 
>> 81:     public void classPrepared(ClassPrepareEvent event) {
>> 82:         try {
>> 83:             ++classPreparedCount;
> 
> It's a long time since I looked at at test based on TestScaffold. Would I be correct to say that it creates an event  handler thread to remove events from the event queue and dispatch them to the registered listeners? Only asking as it's not immediately clear if the increment of the event count is correct. I think TestScaffold uses one thread but would need to dig into the test infra to be sure.

Yes, one EventHandler thread dispatching to all listeners. More details below:

There is an interface called TargetListener which declares all the event callbacks. TargetAdapter implements TargetListener and provides and empty implementation for each callback. TestScaffold extends TargetAdapter, and each test extends TestScaffold. So every test has default empty implementations of all the callbacks, and can override some (there are a couple of overrides in this tests).

A TargetListener instance gets events by adding itself as a listener using TestScaffold.addListener(). You can see that this test is doing that early on so it gets events.

In addition, some of the TestScaffold APIs will create an instance of a TargetAdapter with one or more event callback overrides, and register that listener. For example, see waitForRequestedEvent(). So it is possible to have 2 or more listeners registered, although as I just pointed out in [JDK-8352759](https://bugs.openjdk.org/browse/JDK-8352759), that can be problematic at times.

TestScaffold always has an EventHandler thread active (and only one). It sits in a loop calling EventQueue.remove(). For any each EventSet received it will iterate over each Event in the EventSet, and for each registered listener, it will call the listener's event callback for that Event.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014962541

From cjplummer at openjdk.org  Wed Mar 26 20:40:10 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 20:40:10 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v2]
In-Reply-To: <luJtnjespQIO1FAT69i6CcEp-po0yuWL0H4Ya2Ip2IQ=.2838b808-4847-4811-9053-2d1201e993f6@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <ww54kk5EamjI53bXGlmiOw7xjVlAqJTA_HVH6zeVRkI=.e911d461-0b08-4652-914f-a3adb267951e@github.com>
 <YgPXfxzjCv8Tculuv7FdCb-DEXTwC01xtEBQZjusrcc=.0b3b0413-8bee-46fe-86b9-f5b97e0ae241@github.com>
 <luJtnjespQIO1FAT69i6CcEp-po0yuWL0H4Ya2Ip2IQ=.2838b808-4847-4811-9053-2d1201e993f6@github.com>
Message-ID: <jfiCayniCKpnN_216L0gJQKnhw0ExZ9SUHpyr78OQcc=.a90abb0c-6ba2-4908-a1a3-493c6d926151@github.com>

On Wed, 26 Mar 2025 20:36:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java line 83:
>> 
>>> 81:     public void classPrepared(ClassPrepareEvent event) {
>>> 82:         try {
>>> 83:             ++classPreparedCount;
>> 
>> It's a long time since I looked at at test based on TestScaffold. Would I be correct to say that it creates an event  handler thread to remove events from the event queue and dispatch them to the registered listeners? Only asking as it's not immediately clear if the increment of the event count is correct. I think TestScaffold uses one thread but would need to dig into the test infra to be sure.
>
> Yes, one EventHandler thread dispatching to all listeners. More details below:
> 
> There is an interface called TargetListener which declares all the event callbacks. TargetAdapter implements TargetListener and provides and empty implementation for each callback. TestScaffold extends TargetAdapter, and each test extends TestScaffold. So every test has default empty implementations of all the callbacks, and can override some (there are a couple of overrides in this tests).
> 
> A TargetListener instance gets events by adding itself as a listener using TestScaffold.addListener(). You can see that this test is doing that early on so it gets events.
> 
> In addition, some of the TestScaffold APIs will create an instance of a TargetAdapter with one or more event callback overrides, and register that listener. For example, see waitForRequestedEvent(). So it is possible to have 2 or more listeners registered, although as I just pointed out in [JDK-8352759](https://bugs.openjdk.org/browse/JDK-8352759), that can be problematic at times.
> 
> TestScaffold always has an EventHandler thread active (and only one). It sits in a loop calling EventQueue.remove(). For any each EventSet received it will iterate over each Event in the EventSet, and for each registered listener, it will call the listener's event callback for that Event.

BTW, classPreparedCount is somewhat unneeded legacy code. Previously I had limited it to 50 events to avoid the VMDisconnected exception, but I got rid of the count check and instead now catch the exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2014964080

From cjplummer at openjdk.org  Wed Mar 26 20:50:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Mar 2025 20:50:36 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v4]
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>

> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  remove unused locals.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24236/files
  - new: https://git.openjdk.org/jdk/pull/24236/files/ea44034c..42fd32e3

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

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

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

From duke at openjdk.org  Wed Mar 26 22:18:05 2025
From: duke at openjdk.org (Larry Cable)
Date: Wed, 26 Mar 2025 22:18:05 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not alive
 error on MacOS 15
Message-ID: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>

on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.

it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.

during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
default behavior to occur, in this case the JVM will be terminated.

this is why some tests are failing with "not alive"

the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).

the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
current masks indicate that the JVM's signals are now being handled.

the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
"AttachNotSupportedException" with a suitable error message.

see also: https://bugs.openjdk.org/browse/JDK-8350766

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

Commit messages:
 - JDK-8344671: jcheck whitespace 'nits'
 - JDK-8344671: added stdbool.h and amended exception msg
 - JDK-89344671: fixed some white space issues
 - JDK-8344671: added test to macos attach code to test for signal handler state prior to sending QUIT, this will obviate early JVM termination when not ready to attach

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

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

From dholmes at openjdk.org  Wed Mar 26 22:18:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 26 Mar 2025 22:18:09 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <L8l7c69kT9j0fpc4X-1EVdyZTBFoSTouUiySiD68zsk=.ba5f33a6-268c-4610-b25f-cf7c7e38ad6d@github.com>

On Mon, 17 Mar 2025 18:26:57 GMT, Larry Cable <duke at openjdk.org> wrote:

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

Thanks very much for fixing this @larry-cable ! Changes look good. Just a few minor nits.

Also you need to remove the ProblemList entries in test/jdk/ProblemList.txt.

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 126:

> 124: 
> 125:    /*
> 126:     * early in the lifetime of a JVM it has not yet initialized its signal handlers, in particular the QUIT

Suggestion:

    * Early in the lifetime of a JVM it has not yet initialized its signal handlers, in particular the QUIT

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 129:

> 127:     * handler, note that the default behavior of QUIT is to terminate the receiving process, if unhandled.
> 128:     *
> 129:     * since we use QUIT to initiate an attach operation, if we signal a JVM during this period early in its

Suggestion:

    * Since we use QUIT to initiate an attach operation, if we signal a JVM during this period early in its

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 133:

> 131:     * are attempting to attach to!
> 132:     *
> 133:     * the following code guards the QUIT delivery by testing the current signal masks

Suggestion:

    * The following code guards the QUIT delivery by testing the current signal masks. It is okay to send QUIT
    * if the signal is caught but not ignored, as that implies a handler has been installed.

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 138:

> 136:     if (sysctl(mib, sizeof(mib) / sizeof(int), &kiproc, &kipsz, NULL, 0) == 0) {
> 137:         const int ignored = (kiproc.kp_proc.p_sigignore & sigmask(SIGQUIT)) != 0;
> 138:         const int caught  = (kiproc.kp_proc.p_sigcatch & sigmask(SIGQUIT))  != 0;

Suggestion:

        const bool ignored = (kiproc.kp_proc.p_sigignore & sigmask(SIGQUIT)) != 0;
        const bool caught  = (kiproc.kp_proc.p_sigcatch & sigmask(SIGQUIT))  != 0;

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 140:

> 138:         const int caught  = (kiproc.kp_proc.p_sigcatch & sigmask(SIGQUIT))  != 0;
> 139: 
> 140:         // *only* send QUIT if the target is ready to catch and handle the signal to avoid default "death" if not

Delete this comment.

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 143:

> 141: 
> 142:         // note: obviously the masks could change between testing and signalling however this is not the
> 143:         // observed behavior of the current JVM implementation.

The mask should only change in one direction - from default behaviour to being handled - so this "race" is not a concern.

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 146:

> 144: 
> 145:         if (caught && !ignored) {
> 146:     	    if (kill((pid_t)pid, SIGQUIT)) {

```suggestion (no implicit booleans)
    	    if (kill((pid_t)pid, SIGQUIT) != 0) {

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 154:

> 152: 	    char msg[100];
> 153:  
> 154: 	    snprintf(msg, sizeof(msg), "%d: state is not ready to participate in attach handshake!", (int)pid);

Suggestion:

	    snprintf(msg, sizeof(msg), "%d: process state is not ready to participate in attach handshake!", (int)pid);

Without the `cmd` the original message didn't quite read right.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24085#pullrequestreview-2692365572
PR Comment: https://git.openjdk.org/jdk/pull/24085#issuecomment-2731246857
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999848252
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999849256
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999849992
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999874844
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999865604
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999864741
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999868536
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r1999869609

From jpai at openjdk.org  Wed Mar 26 22:18:10 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 26 Mar 2025 22:18:10 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <ubbE93PvFjmpHojEVsRIutu408MI-LZKbSxdwBMWhyM=.e8843826-09ee-4c02-bc83-3c94e8cd3b40@github.com>

On Mon, 17 Mar 2025 18:26:57 GMT, Larry Cable <duke at openjdk.org> wrote:

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

jcheck is complaining about some whitespace errors in this PR which is why the RFR email hasn't yet been generated.

Hello Larry, there are a few more whitespace issues that's preventing a RFR from being intiated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24085#issuecomment-2731799261
PR Comment: https://git.openjdk.org/jdk/pull/24085#issuecomment-2755120087

From sspitsyn at openjdk.org  Thu Mar 27 01:15:32 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 27 Mar 2025 01:15:32 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out
Message-ID: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>

This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.

Testing: Ran mach5 tiers 1-6.

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

Commit messages:
 - 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest timed out

Changes: https://git.openjdk.org/jdk/pull/24269/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316682
  Stats: 121 lines in 9 files changed: 69 ins; 33 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/24269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24269/head:pull/24269

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

From sspitsyn at openjdk.org  Thu Mar 27 02:07:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 27 Mar 2025 02:07:07 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <vdq-AtQ8azfQgF2Rjy785k0Pj7Xi1Q2qJh_iLxPGz5w=.ef90f633-61a5-4c04-978e-16230222017f@github.com>

On Thu, 27 Mar 2025 01:10:54 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

The fix contains the following updates:
 - Now the internal function `resume_thread()` is executed in a handshake closure (`JvmtiUnitedHandshakeClosure`). This provides a necessary synchronization with the `suspend_thread()` in a case of self-suspension. It would be even better to execute `suspend_thread()` in a handshake closure as well. But this is harder to make right. It'd still make sense to consider such an update in the future.
 - The `HandshakeState:resume()` is updated to remove the `MutexLocker` and a duplicated check for `!is_suspended`.
 - The `JvmtiVTMSTransition_lock` has been replaced with newly introduced `JvmtiVThreadSuspend_lock` in the implementation of the `JvmtiVTSuspender` functions: `register_all_vthreads_suspend()`, `register_all_vthreads_resume()`, `register_vthread_suspend()`, `register_vthread_resume()`. It is because the resume operations are executed in handshakes now  under protection of the HanshakeState lock and so, need a higher ranked lock.
 - The `JvmtiVTMSTransitionDisabler` has several updates:
    - it does nothing (plays a no-op) if the target virtual thread is executed in a context of current `JavaThread`, so it is trying to disable transitions for itself
 - One entry is removed from the `ProblemList`. It is related to the bug which is a dup of this one.

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

PR Comment: https://git.openjdk.org/jdk/pull/24269#issuecomment-2756268404

From jpai at openjdk.org  Thu Mar 27 02:16:13 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Mar 2025 02:16:13 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v4]
In-Reply-To: <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
Message-ID: <Qdo_OR2Uc31IuLHrKqGbacZpW6aSRjtlcsMzIiThx0U=.d38a1bb6-0a1e-430d-8030-03d5b7114394@github.com>

On Wed, 26 Mar 2025 20:50:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused locals.

Thank you Chris for adding the code comment. The source change and the code comment look good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2719204859

From sspitsyn at openjdk.org  Thu Mar 27 02:18:35 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 27 Mar 2025 02:18:35 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
 timed out [v2]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <zDha5jkc0ajVnhq1bXoOPKQ4M9RXjdDMDfJcq4_ZPtI=.619e6269-1c58-4ab5-9570-9ab397df5922@github.com>

> This fixes the issue with lack of synchronization between JVMTI thread suspend and resume functions in a self-suspend case. More detailed fix description is in the first PR comment.
> 
> Testing: Ran mach5 tiers 1-6.

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  some cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24269/files
  - new: https://git.openjdk.org/jdk/pull/24269/files/f1fb7905..18944347

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

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

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

From jpai at openjdk.org  Thu Mar 27 06:30:09 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Mar 2025 06:30:09 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <Bt-lp9WkFC84miKdklRwKch6r3_L5FuPcwF1-lHVjlc=.fe8003d0-03ca-431b-ab5c-764c14c09532@github.com>

On Mon, 17 Mar 2025 18:26:57 GMT, Larry Cable <duke at openjdk.org> wrote:

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 157:

> 155:             snprintf(msg, sizeof(msg), "pid: %d, state is not ready to participate in attach handshake!", (int)pid);
> 156: 
> 157:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException", msg);

I am not too familiar with JNI. Would it be cleaner/beneficial if this native method just returned `JNI_TRUE`/`JNI_FALSE` to indicate whether or not the `SIGQUIT` was sent and then in the Java code side, handle the `throwIfNotReady` part and create and throw the exception if this function returned `JNI_FALSE` and `throwIfNotReady` was `true`?
Would there be any benefit of doing that in the Java side instead of here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2015747468

From jpai at openjdk.org  Thu Mar 27 06:38:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Mar 2025 06:38:07 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <saL8eQZWaCsxaoydQK2i2Ez5-G5KUnetP5iPMOSHGSU=.c5733274-990a-471b-a581-bfe76a4c7510@github.com>

On Mon, 17 Mar 2025 18:26:57 GMT, Larry Cable <duke at openjdk.org> wrote:

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

I'm guessing it's not going to be easy to introduce a regression test for this change. If so, then the linked JDK issue will need a `noreg` label (likely `noreg-hard`).

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

PR Comment: https://git.openjdk.org/jdk/pull/24085#issuecomment-2756897025

From alanb at openjdk.org  Thu Mar 27 07:52:20 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Mar 2025 07:52:20 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v2]
In-Reply-To: <jfiCayniCKpnN_216L0gJQKnhw0ExZ9SUHpyr78OQcc=.a90abb0c-6ba2-4908-a1a3-493c6d926151@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <ww54kk5EamjI53bXGlmiOw7xjVlAqJTA_HVH6zeVRkI=.e911d461-0b08-4652-914f-a3adb267951e@github.com>
 <YgPXfxzjCv8Tculuv7FdCb-DEXTwC01xtEBQZjusrcc=.0b3b0413-8bee-46fe-86b9-f5b97e0ae241@github.com>
 <luJtnjespQIO1FAT69i6CcEp-po0yuWL0H4Ya2Ip2IQ=.2838b808-4847-4811-9053-2d1201e993f6@github.com>
 <jfiCayniCKpnN_216L0gJQKnhw0ExZ9SUHpyr78OQcc=.a90abb0c-6ba2-4908-a1a3-493c6d926151@github.com>
Message-ID: <HaCGnU8IEIxsrXvYIDTSv4ga56vKcKxPRijKi5cjyV8=.45d484ae-95d0-4b8e-96b7-a6c56c231c4c@github.com>

On Wed, 26 Mar 2025 20:37:46 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yes, one EventHandler thread dispatching to all listeners. More details below:
>> 
>> There is an interface called TargetListener which declares all the event callbacks. TargetAdapter implements TargetListener and provides and empty implementation for each callback. TestScaffold extends TargetAdapter, and each test extends TestScaffold. So every test has default empty implementations of all the callbacks, and can override some (there are a couple of overrides in this tests).
>> 
>> A TargetListener instance gets events by adding itself as a listener using TestScaffold.addListener(). You can see that this test is doing that early on so it gets events.
>> 
>> In addition, some of the TestScaffold APIs will create an instance of a TargetAdapter with one or more event callback overrides, and register that listener. For example, see waitForRequestedEvent(). So it is possible to have 2 or more listeners registered, although as I just pointed out in [JDK-8352759](https://bugs.openjdk.org/browse/JDK-8352759), that can be problematic at times.
>> 
>> TestScaffold always has an EventHandler thread active (and only one). It sits in a loop calling EventQueue.remove(). For any each EventSet received it will iterate over each Event in the EventSet, and for each registered listener, it will call the listener's event callback for that Event.
>
> BTW, classPreparedCount is somewhat unneeded legacy code. Previously I had limited it to 50 events to avoid the VMDisconnected exception, but I got rid of the count check and instead now catch the exception.

Thanks for the expanded comment, it just means that classPreparedCount doesn't need to be volatile, it's only accessed by one thread. For this test it doesn't matter of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2015857410

From alanb at openjdk.org  Thu Mar 27 07:52:19 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 27 Mar 2025 07:52:19 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v4]
In-Reply-To: <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
Message-ID: <9ZYwwW_nrKDOVkyhHLjVPJtUfe-Qn_U8_93vBzvpglw=.a480e6c8-f05d-434c-b3cf-3b8b86b91ddf@github.com>

On Wed, 26 Mar 2025 20:50:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused locals.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2720173139

From stuefe at openjdk.org  Thu Mar 27 08:17:22 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 27 Mar 2025 08:17:22 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <n-KfQHeMAztr7axw_qC-Ac92K_Nx1VOqeVBcciKVWYw=.41d279f0-4b91-4076-aaaa-5460fc4c88d3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
 <1S9u0e21AfElb6hNR-rLXa7JIhyUBE35ePRt1d4vhfs=.639232d7-aa07-4ac2-96b2-a2a5414c0377@github.com>
 <n-KfQHeMAztr7axw_qC-Ac92K_Nx1VOqeVBcciKVWYw=.41d279f0-4b91-4076-aaaa-5460fc4c88d3@github.com>
Message-ID: <3bCMfyyRhqc6WmTZoWKE8kQJhbBJvm2rA2Yn2BSTVww=.56d8efcc-9722-45df-9a9b-87f57ab21696@github.com>

On Wed, 26 Mar 2025 16:43:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > > > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> > > 
> > > 
> > > I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?
> > 
> > 
> > I second @stefank here.
> > Uncommit can fail, ironically, with an ENOMEM : if the uncommit punches a hole into a committed region, this would cause a new new VMA on the kernel-side. This may fail if we run against the limit for VMAs. Forgot what it was, some sysconf setting. All of this is Linux specific, though.
> 
> This happens when we hit the /proc/sys/vm/max_map_count limit, and this immediately crashes the JVM.

Yes, but maybe it shouldn't (see below).

> 
> > I don't think this should be unconditionally a fatal error. Since the allocator (whatever it is) can decide to re-commit the region later, and thus "self-heal" itself.
> 
> Is this referring to failures when we hit the max_map_count limit? I'm not convinced that you can recover from that without immediately hitting the same issue somewhere else in the code.

Well, you could scrape around for a while and maybe not trigger it. E.g. in Metaspace, I uncommit granules, but that is optional. I could just ignore uncommit errors there. In the heap, we could do the same thing. 

After a while, the memory may get reused and thus recommitted, thereby solving the problem.

I admit this problem is a bit theoretical, and it may be acceptable to (continue to) crash at that point, since other allocations - libc, heap etc - will face the same limit. Running against this limit seems rare in my experiences; we mostly saw it with ZGC in the past.

> 
> Or maybe you are thinking about some of the other reasons for the uncommit to fail?

Honestly, I don't know why else uncommit would fail.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2757093258

From coleenp at openjdk.org  Thu Mar 27 11:15:09 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 27 Mar 2025 11:15:09 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v4]
In-Reply-To: <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
Message-ID: <FB_AgON7O9vQB4c7JIcaI2iUtwS1qPwXcAkuYTb4yuo=.560bd265-bb1f-4ad5-aeae-29e61842a17e@github.com>

On Wed, 26 Mar 2025 20:50:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused locals.

src/java.base/share/classes/java/lang/ThreadGroup.java line 661:

> 659:     /**
> 660:      * Returns a snapshot of the subgroups as an array, used by JVMTI.
> 661:      * WARNING: Make sure this method does not trigger any class loading.

Can you say why briefly here?  Because it's called during thread startup and may deadlock with ClassLoad events.  I see the comment in the test but not sure if someone will find it, except through git blame, which might be enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2016261353

From varadam at openjdk.org  Thu Mar 27 11:48:12 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 11:48:12 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <E06CHVVLgEsjNqyLcIoHokyX4Q-LUts9t3kU3BqOkaM=.d2123616-dfa4-466e-93af-b14865a861a9@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

test/hotspot/jtreg/serviceability/attach/AttachAPIv2/StreamingOutputTest.java

Initial failure
Execution failed: `main' threw exception: java.lang.Exception: VM did not logged expected 'executing command setflag, streaming output: 1'

AIX hasn?t adopted changes to support the new protocol version v2 https://github.com/openjdk/jdk/blob/8efd253f3d0a58233c0fde31a9514b8c911c892c/src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java#L114. Additionally aix doesn?t have the changes to support streaming output. The "getversion? command supports an "options" argument which currently takes option  "streaming"which allows client to control streaming/buffered output mode.
On aix, this process uses unix sockets for communications like posix had more similar implementation. Is there anything additional changes I should take care of?


https://github.com/openjdk/jdk/pull/20782#issuecomment-2319508258
https://github.com/openjdk/jdk/pull/23405#issuecomment-2628559151

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

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2757747650

From duke at openjdk.org  Thu Mar 27 13:54:34 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 27 Mar 2025 13:54:34 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <5wBQqxybptneJjhR5usfrqg3PJ7G2PB_sDjUkb4BObM=.fe04a403-64ad-4dc5-b793-b48da01acfd4@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
 <kWSNHJBVi5HMrIpSrgj1W2yy4SqVdvvWLTkR35xILgI=.fd68072f-2fed-4273-83a2-2bbe405b6f79@github.com>
 <5wBQqxybptneJjhR5usfrqg3PJ7G2PB_sDjUkb4BObM=.fe04a403-64ad-4dc5-b793-b48da01acfd4@github.com>
Message-ID: <ktEjMPsI2FYqw8otvarZaOfH8e0NYO30HiH5pA3vzrE=.87126d80-444a-45f1-878f-847470a92a95@github.com>

On Wed, 26 Mar 2025 20:18:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > > > > I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.
> > > > 
> > > > 
> > > > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> > > 
> > > 
> > > I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?
> > 
> > 
> > [`VirtualSpace::shrink_by`](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/virtualspace.cpp#L373) allows uncommit to fail without crashing. I'm not certain of the intention behind that. But it seems like it's because shrinking is an optimization and not always critical that it be done immediately. [[1](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/gc/serial/tenuredGeneration.cpp#L258)]
> 
> The above example shows code that assumes that it is OK to fail uncommitting and continuing. I'm trying to figure it that assumption is true. So, what I meant was that I was looking for a concrete example of a failure mode of uncommit that would be an acceptable (safe) failure to continue executing from. That is, a valid failure that don't mess up the memory in an unpredictable/unknowable way.

So release/uncommit (via mmap,munmap, VirtualFree) could fail due to: ? Bad arguments, or ? The OS encountered an issue out of control of the JVM.

? JVM bug. Reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently. 

?  The only errors that aren't due to bad arugments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit).  VirtualFree only fails due to bad arguments according to windows docs. 

So if there's consensus that ENOMEM is not recoverable (or rare enough to not worry about), then it seems like its OK to fatally fail in all scenarios.

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2758139261

From rehn at openjdk.org  Thu Mar 27 14:32:18 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 27 Mar 2025 14:32:18 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
Message-ID: <Qv4mQCfYY-wxBg1sQjGbftfU68YwBBLGSjUwtpVrNAM=.a60d5570-342f-4be6-88cb-877b2b8198b1@github.com>

> Hi, for you to consider.
> 
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
> This is the initial set of tests, there are many more, but I need to do some more verification for those.
> 
> From bug:
>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>> We add this uarch to CPU feature string.
>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
> 
> Relevant qemu code:
> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
> 
> Relevant hotspot code:
> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
> 
> Tested that the require only filters out tests in qemu+riscv64.
> 
> Thanks!
> 
> /Robbin

Robbin Ehn 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 qemu-user-issues
 - more
 - more
 - native or very long

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24229/files
  - new: https://git.openjdk.org/jdk/pull/24229/files/74a74f4c..965424ac

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

  Stats: 48681 lines in 1482 files changed: 10853 ins; 33181 del; 4647 mod
  Patch: https://git.openjdk.org/jdk/pull/24229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24229/head:pull/24229

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

From cjplummer at openjdk.org  Thu Mar 27 15:30:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 27 Mar 2025 15:30:16 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v4]
In-Reply-To: <FB_AgON7O9vQB4c7JIcaI2iUtwS1qPwXcAkuYTb4yuo=.560bd265-bb1f-4ad5-aeae-29e61842a17e@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
 <FB_AgON7O9vQB4c7JIcaI2iUtwS1qPwXcAkuYTb4yuo=.560bd265-bb1f-4ad5-aeae-29e61842a17e@github.com>
Message-ID: <HBm8O9hHk8gaapWoR-BvOUDrRhSTvDRIU_X4aj5fBMo=.adca5806-5c85-462b-bc59-015d1016dcff@github.com>

On Thu, 27 Mar 2025 11:07:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove unused locals.
>
> src/java.base/share/classes/java/lang/ThreadGroup.java line 661:
> 
>> 659:     /**
>> 660:      * Returns a snapshot of the subgroups as an array, used by JVMTI.
>> 661:      * WARNING: Make sure this method does not trigger any class loading.
> 
> Can you say why briefly here?  Because it's called during thread startup and may deadlock with ClassLoad events.  I see the comment in the test but not sure if someone will find it, except through git blame, which might be enough.

I was trying to avoid getting too much into the weeds with the explanation. There's always that one extra bit of information that would be useful, but after adding that then there's another, and you need to decide when to stop. How about the following (and I really don't want to go any further than this):

     * WARNING: Make sure this method does not trigger any class loading,
     * because a ClassPrepareEvent can deadlock the debugger and debug agent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2016941766

From varadam at openjdk.org  Thu Mar 27 16:54:36 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 27 Mar 2025 16:54:36 GMT
Subject: Withdrawn: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <SO_5Nst90zGUjDQDO0tntpQHz0JCrM6mZ3HSRogYaIc=.ad4f255a-7524-4c3c-80cb-cc58b2885b31@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

This pull request has been closed without being integrated.

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

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

From mli at openjdk.org  Thu Mar 27 18:01:38 2025
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 27 Mar 2025 18:01:38 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <Qv4mQCfYY-wxBg1sQjGbftfU68YwBBLGSjUwtpVrNAM=.a60d5570-342f-4be6-88cb-877b2b8198b1@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <Qv4mQCfYY-wxBg1sQjGbftfU68YwBBLGSjUwtpVrNAM=.a60d5570-342f-4be6-88cb-877b2b8198b1@github.com>
Message-ID: <p3aEXv6eKuMcwQPv5ks-Xp4r9FahaZebQqihAanYBuQ=.9183e101-6cc8-4b75-9e01-5c64b757cc2d@github.com>

On Thu, 27 Mar 2025 14:32:18 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, for you to consider.
>> 
>> These tests constantly fails in qemu-user.
>> Either the require host to be same arch or they are very very slow in emulation.
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>> This is the initial set of tests, there are many more, but I need to do some more verification for those.
>> 
>> From bug:
>>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>>> We add this uarch to CPU feature string.
>>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
>> 
>> Relevant qemu code:
>> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
>> 
>> Relevant hotspot code:
>> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
>> 
>> Tested that the require only filters out tests in qemu+riscv64.
>> 
>> Thanks!
>> 
>> /Robbin
>
> Robbin Ehn 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 qemu-user-issues
>  - more
>  - more
>  - native or very long

I also feel annoying to see some tests fail interminently.

Not sure if I understand the goal of this pr, seems it might not be the best solution to simply disable these tests when running with qemu. My concerns are: qemu is still one of main methods to quickly verify the functionality changes, but when we just disable the failed tests, and maybe in the future disable more and more tests, then qemu is no longer able to play the role it was supposed to play.

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2758972731

From sspitsyn at openjdk.org  Thu Mar 27 20:50:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 27 Mar 2025 20:50:16 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v4]
In-Reply-To: <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
Message-ID: <j4bP2b1UBH_opUO3l4Ksh9Ygikq5XggYG-dlp_F1PWQ=.fcb78029-145e-4736-9424-db189d7c9658@github.com>

On Wed, 26 Mar 2025 20:50:36 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused locals.

The fix looks okay to me. I guess new test fails with a deadlock without your fix.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2723349861

From amenkov at openjdk.org  Thu Mar 27 21:04:10 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 27 Mar 2025 21:04:10 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <1oBEVCWBXmozuxIEAIZUhxQHKc-C7LQ9unqKcrOUkB8=.53f87b6f-8ef5-45e1-99ac-55e1a67c79ba@github.com>

On Sun, 23 Mar 2025 14:33:36 GMT, Varada M <varadam at openjdk.org> wrote:

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

The change looks good.
Couple notes:
- need to update copyright year in VirtualMachineImpl.java
- need to remove StreamingOutputTest.java from problem list (revert JDK-8352393)

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

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2759465481

From cjplummer at openjdk.org  Thu Mar 27 21:47:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 27 Mar 2025 21:47:13 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v4]
In-Reply-To: <j4bP2b1UBH_opUO3l4Ksh9Ygikq5XggYG-dlp_F1PWQ=.fcb78029-145e-4736-9424-db189d7c9658@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <V5_m8bPc_o3F2Mft8UeTG-4HbzJnR1wtTgjjtbkPGqs=.c28f40dc-5954-431b-8908-7f6cb0abc038@github.com>
 <j4bP2b1UBH_opUO3l4Ksh9Ygikq5XggYG-dlp_F1PWQ=.fcb78029-145e-4736-9424-db189d7c9658@github.com>
Message-ID: <3eHuYiCoIzYk-V1brvQI7ROsp2R3jqC-NJ4NuA06TWE=.ef592d9d-a43e-40d7-a945-eb75aa5b850b@github.com>

On Thu, 27 Mar 2025 20:47:31 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The fix looks okay to me. I guess new test fails with a deadlock without your fix.

Yes. That is the failure mode. There is no detecting the failure other than a timeout.

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

PR Comment: https://git.openjdk.org/jdk/pull/24236#issuecomment-2759539617

From duke at openjdk.org  Thu Mar 27 22:19:21 2025
From: duke at openjdk.org (Larry Cable)
Date: Thu, 27 Mar 2025 22:19:21 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v2]
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <-cV2tn9uYIWcQrqu9SN6WDEYyry8IiwLoF_u6kHt7vM=.4e4605f7-9951-4073-83ea-2e16bd77e2b3@github.com>

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

Larry Cable has updated the pull request incrementally with three additional commits since the last revision:

 - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24085/files
  - new: https://git.openjdk.org/jdk/pull/24085/files/00161668..b2f465e4

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

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

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

From duke at openjdk.org  Thu Mar 27 22:19:22 2025
From: duke at openjdk.org (Larry Cable)
Date: Thu, 27 Mar 2025 22:19:22 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v2]
In-Reply-To: <Bt-lp9WkFC84miKdklRwKch6r3_L5FuPcwF1-lHVjlc=.fe8003d0-03ca-431b-ab5c-764c14c09532@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <Bt-lp9WkFC84miKdklRwKch6r3_L5FuPcwF1-lHVjlc=.fe8003d0-03ca-431b-ab5c-764c14c09532@github.com>
Message-ID: <k1dTuFtIHnSJK9XVi5LYkC2BxFe-j6PJfyfbJ1WK2X0=.2f9252ad-2e37-4b71-a32b-a2c696727315@github.com>

On Thu, 27 Mar 2025 06:27:44 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 157:
> 
>> 155:             snprintf(msg, sizeof(msg), "pid: %d, state is not ready to participate in attach handshake!", (int)pid);
>> 156: 
>> 157:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException", msg);
> 
> I am not too familiar with JNI. Would it be cleaner/beneficial if this native method just returned `JNI_TRUE`/`JNI_FALSE` to indicate whether or not the `SIGQUIT` was sent and then in the Java code side, handle the `throwIfNotReady` part and create and throw the exception if this function returned `JNI_FALSE` and `throwIfNotReady` was `true`?
> Would there be any benefit of doing that in the Java side instead of here?

it would be different not necessarily better and this is the same pattern as is used for the pre-existing Linux imp

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2017663410

From duke at openjdk.org  Thu Mar 27 22:27:05 2025
From: duke at openjdk.org (Larry Cable)
Date: Thu, 27 Mar 2025 22:27:05 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

Larry Cable has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
 - JDK-8344671: removed JFR tests from problemlist resolved by this fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24085/files
  - new: https://git.openjdk.org/jdk/pull/24085/files/b2f465e4..acd32c1a

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

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

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

From dholmes at openjdk.org  Fri Mar 28 05:44:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 05:44:09 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>
Message-ID: <GbIv2DfIyuxPFNFxeBi6mb8qLH5VZX1K8zpfhIn354Y=.a9a9be01-37b1-4cdf-9795-7d135941a49a@github.com>

On Thu, 27 Mar 2025 22:27:05 GMT, Larry Cable <duke at openjdk.org> wrote:

>> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
>> 
>> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
>> 
>> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
>> default behavior to occur, in this case the JVM will be terminated.
>> 
>> this is why some tests are failing with "not alive"
>> 
>> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
>> 
>> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
>> current masks indicate that the JVM's signals are now being handled.
>> 
>> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
>> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
>> "AttachNotSupportedException" with a suitable error message.
>> 
>> see also: https://bugs.openjdk.org/browse/JDK-8350766
>
> Larry Cable has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
>  - JDK-8344671: removed JFR tests from problemlist resolved by this fix

Looks good. Just a couple of remaining nits. Thanks.

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 148:

> 146: 
> 147:         if (caught && !ignored) {
> 148:             if (kill((pid_t)pid, SIGQUIT)) {

Style nit: no implicit booleans
Suggestion:

            if (kill((pid_t)pid, SIGQUIT) != 0) {

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24085#pullrequestreview-2724337304
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2017961485

From dholmes at openjdk.org  Fri Mar 28 05:44:10 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 28 Mar 2025 05:44:10 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <L8l7c69kT9j0fpc4X-1EVdyZTBFoSTouUiySiD68zsk=.ba5f33a6-268c-4610-b25f-cf7c7e38ad6d@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <L8l7c69kT9j0fpc4X-1EVdyZTBFoSTouUiySiD68zsk=.ba5f33a6-268c-4610-b25f-cf7c7e38ad6d@github.com>
Message-ID: <kPgLuNcutiyNm2o9-rn3AGCfr0_F4ywvzUPpjOghyKA=.f3ed8cc7-964f-4ac1-8fd6-191ad6c93ee6@github.com>

On Mon, 17 Mar 2025 23:44:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
>>  - JDK-8344671: removed JFR tests from problemlist resolved by this fix
>
> src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 140:
> 
>> 138:         const int caught  = (kiproc.kp_proc.p_sigcatch & sigmask(SIGQUIT))  != 0;
>> 139: 
>> 140:         // *only* send QUIT if the target is ready to catch and handle the signal to avoid default "death" if not
> 
> Delete this comment.

Please delete as we have already said this above at line 134-135.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2017959863

From sspitsyn at openjdk.org  Fri Mar 28 06:12:13 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 28 Mar 2025 06:12:13 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>
Message-ID: <2Xn8rHJMKGNCU7IVKiR_PG90KiG3OOqFsyD-6OdoGkM=.6c390a50-bc8b-43ff-a7e2-991650aeee77@github.com>

On Thu, 27 Mar 2025 22:27:05 GMT, Larry Cable <duke at openjdk.org> wrote:

>> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
>> 
>> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
>> 
>> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
>> default behavior to occur, in this case the JVM will be terminated.
>> 
>> this is why some tests are failing with "not alive"
>> 
>> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
>> 
>> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
>> current masks indicate that the JVM's signals are now being handled.
>> 
>> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
>> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
>> "AttachNotSupportedException" with a suitable error message.
>> 
>> see also: https://bugs.openjdk.org/browse/JDK-8350766
>
> Larry Cable has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
>  - JDK-8344671: removed JFR tests from problemlist resolved by this fix

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 140:

> 138:     if (sysctl(mib, sizeof(mib) / sizeof(int), &kiproc, &kipsz, NULL, 0) == 0) {
> 139:         const bool ignored = (kiproc.kp_proc.p_sigignore & sigmask(SIGQUIT)) != 0;
> 140:         const bool caught  = (kiproc.kp_proc.p_sigcatch & sigmask(SIGQUIT))  != 0;

Nit: Past tense in mask bit value names is a little bit confusing here.
Would it better to name them `ignore` and `catch` or `ignore_bit` and `catch_bit`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2017984180

From rehn at openjdk.org  Fri Mar 28 06:56:21 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 28 Mar 2025 06:56:21 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <p3aEXv6eKuMcwQPv5ks-Xp4r9FahaZebQqihAanYBuQ=.9183e101-6cc8-4b75-9e01-5c64b757cc2d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
 <Qv4mQCfYY-wxBg1sQjGbftfU68YwBBLGSjUwtpVrNAM=.a60d5570-342f-4be6-88cb-877b2b8198b1@github.com>
 <p3aEXv6eKuMcwQPv5ks-Xp4r9FahaZebQqihAanYBuQ=.9183e101-6cc8-4b75-9e01-5c64b757cc2d@github.com>
Message-ID: <1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>

On Thu, 27 Mar 2025 17:57:37 GMT, Hamlin Li <mli at openjdk.org> wrote:

> I also feel annoying to see some tests fail interminently.
> 
> Not sure if I understand the goal of this pr, seems it might not be the best solution to simply disable these tests when running with qemu. My concerns are: qemu is still one of main methods to quickly verify the functionality changes, but when we just disable the failed tests, and maybe in the future disable more and more tests, then qemu is no longer able to play the role it was supposed to play.

It's not some intermittently failure. The majority of them can't work as they use pstack, open core files, use PerfData, etc.. and expected it to be rv64. But core files, pstack are in host arch as we are running qemu-user.
I can remove tests which timeouts and only keep test which simply can't work in qemu-user environment in this PR.
Seems good?

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

PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2760381837

From varadam at openjdk.org  Fri Mar 28 08:48:27 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 28 Mar 2025 08:48:27 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v2]
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <L7Q0uo9u_dIiITmbEKyKGVdRh7xfN94LqdJ8bRgIYXM=.5654dd84-a53e-45d4-ae5a-956afd020d33@github.com>

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

Varada M 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 test-fix
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: implement attach API v2 and streaming output
 - AIX: Problem list serviceability/attach/AttachAPIv2/StreamingOutputTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24177/files
  - new: https://git.openjdk.org/jdk/pull/24177/files/8efd253f..ab6941f2

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

  Stats: 59685 lines in 1814 files changed: 15314 ins; 37325 del; 7046 mod
  Patch: https://git.openjdk.org/jdk/pull/24177.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24177/head:pull/24177

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

From varadam at openjdk.org  Fri Mar 28 09:01:26 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 28 Mar 2025 09:01:26 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v3]
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>

> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
> 
> tier1, tier2 and tier3 testing is successful with fastdebug level
> 
> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)

Varada M has updated the pull request incrementally with two additional commits since the last revision:

 - updated copyright header
 - removed StreamingOutputTest.java from problem list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24177/files
  - new: https://git.openjdk.org/jdk/pull/24177/files/ab6941f2..d22f0ab9

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

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

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

From varadam at openjdk.org  Fri Mar 28 09:01:26 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 28 Mar 2025 09:01:26 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
In-Reply-To: <1oBEVCWBXmozuxIEAIZUhxQHKc-C7LQ9unqKcrOUkB8=.53f87b6f-8ef5-45e1-99ac-55e1a67c79ba@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
 <1oBEVCWBXmozuxIEAIZUhxQHKc-C7LQ9unqKcrOUkB8=.53f87b6f-8ef5-45e1-99ac-55e1a67c79ba@github.com>
Message-ID: <DPmPD-tg8BQ_KwTlvkg3mfJDviY47-CQVwfqWdfzCFI=.ff30ceb5-bd8d-48e3-b202-e511e9aba3c0@github.com>

On Thu, 27 Mar 2025 21:01:29 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
>> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
>> 
>> tier1, tier2 and tier3 testing is successful with fastdebug level
>> 
>> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)
>
> The change looks good.
> Couple notes:
> - need to update copyright year in VirtualMachineImpl.java
> - need to remove StreamingOutputTest.java from problem list (revert JDK-8352393)

Thank you @alexmenkov, I have updated copyright year and reverted the changes from JDK-8352393.

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

PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2760600605

From stuefe at openjdk.org  Fri Mar 28 09:48:27 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 28 Mar 2025 09:48:27 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <ktEjMPsI2FYqw8otvarZaOfH8e0NYO30HiH5pA3vzrE=.87126d80-444a-45f1-878f-847470a92a95@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
 <kWSNHJBVi5HMrIpSrgj1W2yy4SqVdvvWLTkR35xILgI=.fd68072f-2fed-4273-83a2-2bbe405b6f79@github.com>
 <5wBQqxybptneJjhR5usfrqg3PJ7G2PB_sDjUkb4BObM=.fe04a403-64ad-4dc5-b793-b48da01acfd4@github.com>
 <ktEjMPsI2FYqw8otvarZaOfH8e0NYO30HiH5pA3vzrE=.87126d80-444a-45f1-878f-847470a92a95@github.com>
Message-ID: <j1fw14CTmCprVIaJLulAmVLGpxwuhF07Sm77y5UY7QI=.65845fc1-56ba-4b3f-afc0-0b41517e9dc9@github.com>

On Thu, 27 Mar 2025 13:51:51 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> > > > > > I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.
> > > > > 
> > > > > 
> > > > > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> > > > 
> > > > 
> > > > I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?
> > > 
> > > 
> > > [`VirtualSpace::shrink_by`](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/virtualspace.cpp#L373) allows uncommit to fail without crashing. I'm not certain of the intention behind that. But it seems like it's because shrinking is an optimization and not always critical that it be done immediately. [[1](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/gc/serial/tenuredGeneration.cpp#L258)]
> > 
> > 
> > The above example shows code that assumes that it is OK to fail uncommitting and continuing. I'm trying to figure it that assumption is true. So, what I meant was that I was looking for a concrete example of a failure mode of uncommit that would be an acceptable (safe) failure to continue executing from. That is, a valid failure that don't mess up the memory in an unpredictable/unknowable way.
> 
> So release/uncommit (via mmap,munmap, VirtualFree) could fail due to: ? Bad arguments, or ? The OS encountered an issue out of control of the JVM.
> 
> ? JVM bug. Reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently.
> 
> ? The only errors that aren't due to bad arugments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit). VirtualFree only fails due to bad arguments according to windows docs.
> 
> So if there's consensus that ENOMEM is not recoverable (or rare enough to not worry about), then it seems like its OK to fatally fail in all scenarios.

+1

Thanks for investigating the details of this (also nothing we couldn't change later if it bugs us).

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2760736918

From jpai at openjdk.org  Fri Mar 28 09:48:42 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 28 Mar 2025 09:48:42 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <k1dTuFtIHnSJK9XVi5LYkC2BxFe-j6PJfyfbJ1WK2X0=.2f9252ad-2e37-4b71-a32b-a2c696727315@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <Bt-lp9WkFC84miKdklRwKch6r3_L5FuPcwF1-lHVjlc=.fe8003d0-03ca-431b-ab5c-764c14c09532@github.com>
 <k1dTuFtIHnSJK9XVi5LYkC2BxFe-j6PJfyfbJ1WK2X0=.2f9252ad-2e37-4b71-a32b-a2c696727315@github.com>
Message-ID: <40zgy50dP_txP-WXuMVWFA1Vkju5G8V6qMlAtMVajUI=.073eb958-c864-4860-9385-f882698e67e8@github.com>

On Thu, 27 Mar 2025 22:13:17 GMT, Larry Cable <duke at openjdk.org> wrote:

>> src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 157:
>> 
>>> 155:             snprintf(msg, sizeof(msg), "pid: %d, state is not ready to participate in attach handshake!", (int)pid);
>>> 156: 
>>> 157:             JNU_ThrowByName(env, "com/sun/tools/attach/AttachNotSupportedException", msg);
>> 
>> I am not too familiar with JNI. Would it be cleaner/beneficial if this native method just returned `JNI_TRUE`/`JNI_FALSE` to indicate whether or not the `SIGQUIT` was sent and then in the Java code side, handle the `throwIfNotReady` part and create and throw the exception if this function returned `JNI_FALSE` and `throwIfNotReady` was `true`?
>> Would there be any benefit of doing that in the Java side instead of here?
>
> it would be different not necessarily better and this is the same pattern as is used for the pre-existing Linux imp

I see. Thank you Larry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2018259411

From mbaesken at openjdk.org  Fri Mar 28 13:21:25 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 28 Mar 2025 13:21:25 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
Message-ID: <KRdW41Hf3wdnTLkZtPL1Z_x5nSonKm36STgNMzKwArw=.5e0f7991-4099-4944-b7f0-6f6e535e4865@github.com>

On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX.
> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there.
> 
> On Linux x86_64 for example the lib shrinks from
> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M .
> 
> On Linux ppc64le for example the lib shrinks from
> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M .

The results for LOW/SIZE/HIGHEST  for LIBJDWP  are here  (at least for our build envs at SAP) 
https://wiki.openjdk.org/display/Build/Native+library+optimization+level+research

>From what I see,  if we really care about speed in this lib we could also use HIGHEST optimization;  there is not much code bloat with this.
If we care about size of the lib/image size, SIZE brings us some improvements especially on Linux.
I can also try HIGHEST + lto (this might bring us speed + smaller lib size at least with gcc).

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

PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2761344464

From duke at openjdk.org  Fri Mar 28 17:17:01 2025
From: duke at openjdk.org (Larry Cable)
Date: Fri, 28 Mar 2025 17:17:01 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v4]
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <qdjAuLRJIHftKSEjejAuWCI2xcVzvBflobROie_8y1E=.70f80ce0-b951-4b45-827c-cdc469005aeb@github.com>

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

Larry Cable has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
  
  closing the stable door after the horse has bolted
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24085/files
  - new: https://git.openjdk.org/jdk/pull/24085/files/acd32c1a..9b81d337

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

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

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

From duke at openjdk.org  Fri Mar 28 17:17:02 2025
From: duke at openjdk.org (Larry Cable)
Date: Fri, 28 Mar 2025 17:17:02 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <2Xn8rHJMKGNCU7IVKiR_PG90KiG3OOqFsyD-6OdoGkM=.6c390a50-bc8b-43ff-a7e2-991650aeee77@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>
 <2Xn8rHJMKGNCU7IVKiR_PG90KiG3OOqFsyD-6OdoGkM=.6c390a50-bc8b-43ff-a7e2-991650aeee77@github.com>
Message-ID: <sI0GhinOUw43M3NOrzyKPll-r5t5TG5r-kSUBntdoH0=.39ba2d91-fadf-412d-b544-8a1d035e5e7c@github.com>

On Fri, 28 Mar 2025 06:09:53 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
>>  - JDK-8344671: removed JFR tests from problemlist resolved by this fix
>
> src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 140:
> 
>> 138:     if (sysctl(mib, sizeof(mib) / sizeof(int), &kiproc, &kipsz, NULL, 0) == 0) {
>> 139:         const bool ignored = (kiproc.kp_proc.p_sigignore & sigmask(SIGQUIT)) != 0;
>> 140:         const bool caught  = (kiproc.kp_proc.p_sigcatch & sigmask(SIGQUIT))  != 0;
> 
> Nit: Past tense in mask bit value names is a little bit confusing here.
> Would it better to name them `ignore` and `catch` or `ignore_bit` and `catch_bit`?

"is SIGQUIT caught or ignored" ... I see no confusion here...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2019045469

From duke at openjdk.org  Fri Mar 28 17:17:03 2025
From: duke at openjdk.org (Larry Cable)
Date: Fri, 28 Mar 2025 17:17:03 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <GbIv2DfIyuxPFNFxeBi6mb8qLH5VZX1K8zpfhIn354Y=.a9a9be01-37b1-4cdf-9795-7d135941a49a@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>
 <GbIv2DfIyuxPFNFxeBi6mb8qLH5VZX1K8zpfhIn354Y=.a9a9be01-37b1-4cdf-9795-7d135941a49a@github.com>
Message-ID: <5feRMdJjg14CGBZAHG1_7ZOqu6IQ5IJoR1n9hV5tFrg=.f4396215-82d8-4db7-92ce-e4c70dd72ba9@github.com>

On Fri, 28 Mar 2025 05:39:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Larry Cable has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
>>  - JDK-8344671: removed JFR tests from problemlist resolved by this fix
>
> src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 148:
> 
>> 146: 
>> 147:         if (caught && !ignored) {
>> 148:             if (kill((pid_t)pid, SIGQUIT)) {
> 
> Style nit: no implicit booleans
> Suggestion:
> 
>             if (kill((pid_t)pid, SIGQUIT) != 0) {

note that I did not modify this line of code, it is as it was prior to my changes!

closing the stable door after the horse has bolted!m

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2019048154

From amenkov at openjdk.org  Fri Mar 28 20:09:18 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 28 Mar 2025 20:09:18 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v3]
In-Reply-To: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
 <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
Message-ID: <i-h-6u3UzxOKhbEmpeTslcfkyoad1zwYk9DVF6YpgQk=.b3e1601e-9501-4f14-a4ed-39ba07fa7419@github.com>

On Fri, 28 Mar 2025 09:01:26 GMT, Varada M <varadam at openjdk.org> wrote:

>> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
>> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
>> 
>> tier1, tier2 and tier3 testing is successful with fastdebug level
>> 
>> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)
>
> Varada M has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated copyright header
>  - removed StreamingOutputTest.java from problem list

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2726618858

From cjplummer at openjdk.org  Fri Mar 28 21:02:21 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 28 Mar 2025 21:02:21 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v6]
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>

> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  undo change that wasn't suppose to be committed.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24236/files
  - new: https://git.openjdk.org/jdk/pull/24236/files/3d241742..977ecf15

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

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

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

From sspitsyn at openjdk.org  Sat Mar 29 02:44:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 29 Mar 2025 02:44:16 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v6]
In-Reply-To: <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>
Message-ID: <VezEQK4mZ1hEkIVv-u7wOaxAu7QUgoER9tm05n68muo=.ccec66a3-033d-4adb-8d35-5221d449ea71@github.com>

On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo change that wasn't suppose to be committed.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2727221595

From jpai at openjdk.org  Sat Mar 29 04:35:07 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 29 Mar 2025 04:35:07 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v6]
In-Reply-To: <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>
Message-ID: <M1CWTkvGLrcBN2i8sWv-vEdUmN7LK3xhshEPWg2_ndU=.08fad6e0-aa4d-49dc-9b79-81cb650e27b0@github.com>

On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo change that wasn't suppose to be committed.

Still looks good.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2727249815

From alanb at openjdk.org  Sat Mar 29 08:58:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 29 Mar 2025 08:58:11 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v6]
In-Reply-To: <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>
Message-ID: <R3BGAr3z-JaRO5KzbxGXAwINsLuPw3PfdSWlxSDKtPE=.88023a8a-804f-4b0e-81e0-007161217aa1@github.com>

On Fri, 28 Mar 2025 21:02:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Calling ThreadGroupReference.groups() from an event handler can cause a deadlock. Details in first comment. Tested with :jdk_lang on all supported platforms and tier1, tier2, tier3, and tier5 svc testing.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo change that wasn't suppose to be committed.

src/java.base/share/classes/java/lang/ThreadGroup.java line 662:

> 660:      * Returns a snapshot of the subgroups as an array, used by JVMTI.
> 661:      * WARNING: Make sure this method does not trigger any class loading,
> 662:      * because a ClassPrepareEvent can deadlock the debugger and debug agent.

The comment is okay but if you are doing any further edits then you could change this to say that a callback for the ClassPrepare event can deadlock (the event is "ClassPrepare" in the JVM TI spec, I realize the "ClassPrepareEvent" may have come from JDI).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2019756430

From dholmes at openjdk.org  Mon Mar 31 03:03:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 03:03:19 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v4]
In-Reply-To: <qdjAuLRJIHftKSEjejAuWCI2xcVzvBflobROie_8y1E=.70f80ce0-b951-4b45-827c-cdc469005aeb@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <qdjAuLRJIHftKSEjejAuWCI2xcVzvBflobROie_8y1E=.70f80ce0-b951-4b45-827c-cdc469005aeb@github.com>
Message-ID: <hQS_bo5z7JWNw8_JpPFkI-ui-IrTts_89as9Pg9YsaU=.b71e0ccb-9f24-474d-8bc5-70fa5678c85e@github.com>

On Fri, 28 Mar 2025 17:17:01 GMT, Larry Cable <duke at openjdk.org> wrote:

>> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
>> 
>> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
>> 
>> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
>> default behavior to occur, in this case the JVM will be terminated.
>> 
>> this is why some tests are failing with "not alive"
>> 
>> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
>> 
>> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
>> current masks indicate that the JVM's signals are now being handled.
>> 
>> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
>> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
>> "AttachNotSupportedException" with a suitable error message.
>> 
>> see also: https://bugs.openjdk.org/browse/JDK-8350766
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c
>   
>   closing the stable door after the horse has bolted
>   
>   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

Marked as reviewed by dholmes (Reviewer).

src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 142:

> 140:         const bool caught  = (kiproc.kp_proc.p_sigcatch & sigmask(SIGQUIT))  != 0;
> 141: 
> 142:         // *only* send QUIT if the target is ready to catch and handle the signal to avoid default "death" if not

Re-requesting this comment be deleted as it effectively just repeats what the expanded comments above already say. Thanks

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

PR Review: https://git.openjdk.org/jdk/pull/24085#pullrequestreview-2728168003
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2020361432

From dholmes at openjdk.org  Mon Mar 31 03:03:20 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 03:03:20 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v3]
In-Reply-To: <5feRMdJjg14CGBZAHG1_7ZOqu6IQ5IJoR1n9hV5tFrg=.f4396215-82d8-4db7-92ce-e4c70dd72ba9@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <AUDDS4lsZpc1pWpYJ3Sb_lEBdi1AZedjf5JxOVRCpqI=.78fe964b-3c80-40c4-a7ce-0b5025782dc3@github.com>
 <GbIv2DfIyuxPFNFxeBi6mb8qLH5VZX1K8zpfhIn354Y=.a9a9be01-37b1-4cdf-9795-7d135941a49a@github.com>
 <5feRMdJjg14CGBZAHG1_7ZOqu6IQ5IJoR1n9hV5tFrg=.f4396215-82d8-4db7-92ce-e4c70dd72ba9@github.com>
Message-ID: <cFBRHYgfMmGZyruKr_yoeQY-cxQTHOfS2aMTr_APoH8=.57ecb823-7747-4739-af46-a8146cfe2b6d@github.com>

On Fri, 28 Mar 2025 17:13:27 GMT, Larry Cable <duke at openjdk.org> wrote:

>> src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 148:
>> 
>>> 146: 
>>> 147:         if (caught && !ignored) {
>>> 148:             if (kill((pid_t)pid, SIGQUIT)) {
>> 
>> Style nit: no implicit booleans
>> Suggestion:
>> 
>>             if (kill((pid_t)pid, SIGQUIT) != 0) {
>
> note that I did not modify this line of code, it is as it was prior to my changes!
> 
> closing the stable door after the horse has bolted!m

Noted. But good to clean up whilst making significant code changes. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2020360775

From mdoerr at openjdk.org  Mon Mar 31 10:21:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 31 Mar 2025 10:21:20 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
 [v3]
In-Reply-To: <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
 <4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
Message-ID: <ydGbLAEY5w_ctvhNUo3MRCBlLnpR_nKt_Ebl8bgt9s4=.172711d4-cc4a-4d4c-9164-519e8060b7b6@github.com>

On Fri, 28 Mar 2025 09:01:26 GMT, Varada M <varadam at openjdk.org> wrote:

>> AIX changes for attach API to support arbitrary length arguments and the streaming output support. 
>> serviceability/attach/AttachAPIv2/StreamingOutputTest.java test passes
>> 
>> tier1, tier2 and tier3 testing is successful with fastdebug level
>> 
>> JBS Issue : [JDK-8352392](https://bugs.openjdk.org/browse/JDK-8352392)
>
> Varada M has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated copyright header
>  - removed StreamingOutputTest.java from problem list

I think this is good. @JoKern65: Do you also want to review it?

src/hotspot/os/aix/attachListener_aix.cpp line 119:

> 117:   void close() {
> 118:     if (opened()) {
> 119:       ::shutdown(_socket, 2);

If there is no macro like `SHUT_RDWR` available, maybe add it as a comment?

src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 125:

> 123:              } finally {
> 124:                  close(s);
> 125:              }

Indentation is off by 1 in this hunk.

src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 196:

> 194:          }
> 195:      }
> 196: 

Same here.

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

PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2728824060
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2020765326
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2020767818
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2020768721

From rehn at openjdk.org  Mon Mar 31 10:45:54 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 31 Mar 2025 10:45:54 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
Message-ID: <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>

> Hi, for you to consider.
> 
> These tests constantly fails in qemu-user.
> Either the require host to be same arch or they are very very slow in emulation.
> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
> This is the initial set of tests, there are many more, but I need to do some more verification for those.
> 
> From bug:
>> qemu-user/rv64 sets uarch to "qemu" in /proc/cpuinfo (qemu-system do not do that).
>> We add this uarch to CPU feature string.
>> This means we can use jtreg 'require' with cpu string to filter out tests in qemu-user.
> 
> Relevant qemu code:
> https://github.com/qemu/qemu/blob/170825d14d88a1ce7fae98d5a928480f2f329b22/linux-user/riscv/target_proc.h#L29
> 
> Relevant hotspot code:
> https://github.com/openjdk/jdk/blob/fa0b18bfde38ee2ffbab33a9eaac547fe8aa3c7c/src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp#L250
> 
> Tested that the require only filters out tests in qemu+riscv64.
> 
> Thanks!
> 
> /Robbin

Robbin Ehn 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 qemu-user-issues
 - Revert
 - Merge branch 'master' into qemu-user-issues
 - Merge branch 'master' into qemu-user-issues
 - more
 - more
 - native or very long

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24229/files
  - new: https://git.openjdk.org/jdk/pull/24229/files/965424ac..73968ab8

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

  Stats: 9932 lines in 248 files changed: 5027 ins; 4362 del; 543 mod
  Patch: https://git.openjdk.org/jdk/pull/24229.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24229/head:pull/24229

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

From stefank at openjdk.org  Mon Mar 31 12:22:18 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 31 Mar 2025 12:22:18 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <j1fw14CTmCprVIaJLulAmVLGpxwuhF07Sm77y5UY7QI=.65845fc1-56ba-4b3f-afc0-0b41517e9dc9@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
 <MSq1c_JDyl3X9W5qYK7vdLjN4z5xnV6qNz6jwNVG5kk=.5ad7f502-9156-47bb-9e52-8e09da8fce3d@github.com>
 <x0JtaYq7XWUXOWaxzcysSXYkKtRSmEDphmAp58ikccY=.68684507-e52c-46cf-8ab7-4cd7acd52e92@github.com>
 <hJdWyT2ADI-YZr8PgwT00B12lPcNxq9SAdCsXlRbD28=.f2189c17-1202-4bc4-85c7-8a40a1d0412d@github.com>
 <3zkHWLVEELkQkeSU9M0YAOpb3olMDNyU1HAdWUJEm68=.a2d2f9ea-c635-4379-95d7-00ff358eb15f@github.com>
 <zKYYPOaJCBPhGGqQs_jqkJfNhzGhTLFcry-ozmEvRRg=.667a0fa9-0ea3-4464-8ee5-f1efc6a2d01c@github.com>
 <kWSNHJBVi5HMrIpSrgj1W2yy4SqVdvvWLTkR35xILgI=.fd68072f-2fed-4273-83a2-2bbe405b6f79@github.com>
 <5wBQqxybptneJjhR5usfrqg3PJ7G2PB_sDjUkb4BObM=.fe04a403-64ad-4dc5-b793-b48da01acfd4@github.com>
 <ktEjMPsI2FYqw8otvarZaOfH8e0NYO30HiH5pA3vzrE=.87126d80-444a-45f1-878f-847470a92a95@github.com>
 <j1fw14CTmCprVIaJLulAmVLGpxwuhF07Sm77y5UY7QI=.65845fc1-56ba-4b3f-afc0-0b41517e9dc9@github.com>
Message-ID: <f4p26hxqfHgRqqT5JWDffkmrr1FYGu7I4byyFyiHkF4=.0cd0c90b-2dec-4ad0-96f0-e25023cf6af2@github.com>

On Fri, 28 Mar 2025 09:44:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > > > > > I don't understand why we don't treat that as a fatal error OR make sure that all call-sites handles that error, which they don't do today.
> > > > > > 
> > > > > > 
> > > > > > I think release/uncommit failures should be handled by the callers. Currently, uncommit failure is handled in most places by the caller, release failure seems mostly not. Since, at least for uncommit, we could sometimes fail for valid reasons, I think we shouldn't fail fatally in the os:: functions.
> > > > > 
> > > > > 
> > > > > I would like to drill a bit deeper into this. Do you have any concrete examples of an uncommit failure that should not be handled as a fatal error?
> > > > 
> > > > 
> > > > [`VirtualSpace::shrink_by`](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/memory/virtualspace.cpp#L373) allows uncommit to fail without crashing. I'm not certain of the intention behind that. But it seems like it's because shrinking is an optimization and not always critical that it be done immediately. [[1](https://github.com/openjdk/jdk/blob/jdk-25%2B15/src/hotspot/share/gc/serial/tenuredGeneration.cpp#L258)]
> > > 
> > > 
> > > The above example shows code that assumes that it is OK to fail uncommitting and continuing. I'm trying to figure it that assumption is true. So, what I meant was that I was looking for a concrete example of a failure mode of uncommit that would be an acceptable (safe) failure to continue executing from. That is, a valid failure that don't mess up the memory in an unpredictable/unknowable way.
> > 
> > 
> > So release/uncommit (via mmap,munmap, VirtualFree) could fail due to: ? Bad arguments, or ? The OS encountered an issue out of control of the JVM.
> > ? JVM bug. Reasonable to fatally fail here. Or the caller could be intentionally passing arguments that may or may not be valid. I don't think there is any code like that currently.
> > ? The only errors that aren't due to bad arugments are ENOMEM and ones related to file descriptors (which are not applicable to uncommit). VirtualFree only fails due to bad arguments according to windows docs.
> > So if there's consensus that ENOMEM is not recoverable (or rare enough to not worry about), then it seems like its OK to fatally fail in all scenarios.
> 
> +1
> 
> Thanks for investigating the details of this (also nothing we couldn't change later if it bugs us).

+1

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2766054807

From duke at openjdk.org  Mon Mar 31 14:12:29 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 31 Mar 2025 14:12:29 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
 protected by NMT lock
In-Reply-To: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
Message-ID: <h4NKslnaVrulREkzTc7CuQh_0l5QTLA100GRkfhApEk=.e71e26d2-53bc-4960-93eb-ac4afc215e39@github.com>

On Mon, 17 Mar 2025 16:20:42 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> ### Summary:
> This PR makes memory operations atomic with NMT accounting.
> 
> ### The problem:
> In memory related functions like `os::commit_memory` and `os::reserve_memory` the OS memory operations are currently done before acquiring the the NMT mutex. And the the virtual memory accounting is done later in `MemTracker`, after the lock has been acquired. Doing the memory operations outside of the lock scope can lead to races. 
> 
> 1.1 Thread_1 releases range_A.
> 1.2 Thread_1 tells NMT "range_A has been released".
> 
> 2.1 Thread_2 reserves (the now free) range_A.
> 2.2 Thread_2 tells NMT "range_A is reserved".
> 
> Since the sequence (1.1)  (1.2) is not atomic, if Thread_2 begins operating after (1.1), we can have (1.1) (2.1) (2.2) (1.2). The OS sees two valid subsequent calls (release range_A, followed by map range_A). But NMT sees "reserve range_A", "release range_A" and is now out of sync with the OS.
> 
> ### Solution:
> Where memory operations such as reserve, commit, or release virtual memory happen,  I've expanded the scope of `NmtVirtualMemoryLocker` to protect both the NMT accounting and the memory operation itself. 
> 
> ### Other notes:
> I also simplified this  pattern found in many places:
> 
> if (MemTracker::enabled()) {
>   MemTracker::NmtVirtualMemoryLocker nvml;
>   result = pd_some_operation(addr, bytes);
>   if (result != nullptr) {
>     MemTracker::record_some_operation(addr, bytes);
>   }
> } else {
>   result = pd_unmap_memory(addr, bytes);
> }
> ``` 
> To:
> 
> MemTracker::NmtVirtualMemoryLocker nvml;
> result = pd_unmap_memory(addr, bytes);
> MemTracker::record_some_operation(addr, bytes);
> ``` 
> This is possible because `NmtVirtualMemoryLocker` now checks `MemTracker::enabled()`.  `MemTracker::record_some_operation` already checks `MemTracker::enabled()` and checks against nullptr.  This refactoring previously wasn't possible because `ThreadCritical` was used before https://github.com/openjdk/jdk/pull/22745 introduced `NmtVirtualMemoryLocker`. 
> 
> I considered moving the locking and NMT accounting down into platform specific code:  Ex. lock around { munmap() + MemTracker::record }. The hope was that this would help reduce the size of the critical section. However, I found that the OS-specific "pd_" functions are already short and to-the-point, so doing this wasn't reducing the lock scope very much. Instead it just makes the code more messy by having to maintain the locking and NMT accounting in each platform specific implementation. 
> 
> In many places I've done minor refactoring by relocating call...

OK should I update this PR to do the following things:
-  Add comments explaining the asymmetrical locking and warning against patterns that lead to races
- swapping the order of `NmtVirtualMemoryLocker` and release/uncommit
- Fail fatally if release/uncommit does not complete.

Or does it make more sense to do that in a different issue/PR?

Also, do we want to keep the new tests and the refactorings (see below)?

if (MemTracker::enabled()) {
  MemTracker::NmtVirtualMemoryLocker nvml;
  result = pd_some_operation(addr, bytes);
  if (result != nullptr) {
    MemTracker::record_some_operation(addr, bytes);
  }
} else {
  result = pd_unmap_memory(addr, bytes);
}

To:

MemTracker::NmtVirtualMemoryLocker nvml;
result = pd_unmap_memory(addr, bytes);
MemTracker::record_some_operation(addr, bytes);

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

PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2766365411

From cjplummer at openjdk.org  Mon Mar 31 17:31:49 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 31 Mar 2025 17:31:49 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
 can lock up target VM [v6]
In-Reply-To: <R3BGAr3z-JaRO5KzbxGXAwINsLuPw3PfdSWlxSDKtPE=.88023a8a-804f-4b0e-81e0-007161217aa1@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
 <guctm8F2iAyWti4Z1ez7Pnu30UB_Wm8M5fhyj8daAas=.f68c2479-b334-4692-afd3-d47aee047fe1@github.com>
 <R3BGAr3z-JaRO5KzbxGXAwINsLuPw3PfdSWlxSDKtPE=.88023a8a-804f-4b0e-81e0-007161217aa1@github.com>
Message-ID: <T9INQGHBhafUwQQjzMgKcRlLWuiTZdcsO2UBlRBWvVc=.5d80cd88-5b26-4cfc-ad08-8bd54e6e4633@github.com>

On Sat, 29 Mar 2025 08:55:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   undo change that wasn't suppose to be committed.
>
> src/java.base/share/classes/java/lang/ThreadGroup.java line 662:
> 
>> 660:      * Returns a snapshot of the subgroups as an array, used by JVMTI.
>> 661:      * WARNING: Make sure this method does not trigger any class loading,
>> 662:      * because a ClassPrepareEvent can deadlock the debugger and debug agent.
> 
> The comment is okay but if you are doing any further edits then you could change this to say that a callback for the ClassPrepare event can deadlock (the event is "ClassPrepare" in the JVM TI spec, I realize the "ClassPrepareEvent" may have come from JDI).

I'd rather not use "callback" here. Even the JVMTI spec mostly documents in terms of events, not callbacks. For example, for the ClassLoad callback it says "For most purposes the ClassPrepare event will be more useful". Maybe as a compromise I can change "ClassPrepareEvent" to "ClassPrepare event".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24236#discussion_r2021443456

From duke at openjdk.org  Mon Mar 31 18:02:12 2025
From: duke at openjdk.org (Larry Cable)
Date: Mon, 31 Mar 2025 18:02:12 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v5]
In-Reply-To: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
Message-ID: <trwkMb0Cfir2Xrwo3sB0Chy7-ejYRseRXwDTpOHxVPA=.8b6bcb66-d864-4b5b-868d-ce7c602ef2ef@github.com>

> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
> 
> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
> 
> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
> default behavior to occur, in this case the JVM will be terminated.
> 
> this is why some tests are failing with "not alive"
> 
> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
> 
> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
> current masks indicate that the JVM's signals are now being handled.
> 
> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
> "AttachNotSupportedException" with a suitable error message.
> 
> see also: https://bugs.openjdk.org/browse/JDK-8350766

Larry Cable has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
 - JDK-8334671: minor changes requested by @dholmes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24085/files
  - new: https://git.openjdk.org/jdk/pull/24085/files/9b81d337..c27af72a

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

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

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

From dholmes at openjdk.org  Mon Mar 31 23:45:43 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 31 Mar 2025 23:45:43 GMT
Subject: RFR: 8344671: Few JFR streaming tests fail with application not
 alive error on MacOS 15 [v5]
In-Reply-To: <trwkMb0Cfir2Xrwo3sB0Chy7-ejYRseRXwDTpOHxVPA=.8b6bcb66-d864-4b5b-868d-ce7c602ef2ef@github.com>
References: <3xUroXKNX4bBRb0L4r5WJ9V_TEJRbtS_hmdZ3AMCTFo=.86aaf7a8-d2c1-4f07-9f74-4e2cab2d0fa2@github.com>
 <trwkMb0Cfir2Xrwo3sB0Chy7-ejYRseRXwDTpOHxVPA=.8b6bcb66-d864-4b5b-868d-ce7c602ef2ef@github.com>
Message-ID: <jcyQ2TqLjfrWXTUseUlzgBUvOJPiBq3wpwsRtrrqjbY=.e1f8e9a3-282d-4287-8d07-86102969b734@github.com>

On Mon, 31 Mar 2025 18:02:12 GMT, Larry Cable <duke at openjdk.org> wrote:

>> on both Linux and MacOS libattach utilizes UNIX signal (QUIT) to cause a target JVM (attachee) to create the socket file used as transport for subsequent jcmds (and other attach based interactions) and to listen upon that for such.
>> 
>> it should be noted that the default behavior for QUIT (if not blocked or caught) is to terminate the signalled process.
>> 
>> during the early lifetime of a JVM, its signal handlers are not yet installed, and thus any signal such as QUIT will cause the
>> default behavior to occur, in this case the JVM will be terminated.
>> 
>> this is why some tests are failing with "not alive"
>> 
>> the "fix" is similar in nature to that already implemented for linux (however using a different OS dependent mechanism to obtain the attachee JVM's signal masks: sysctl(2)).
>> 
>> the method "checkCatchesAndSendQuitTo" will now obtain the "attachee" JVM signal masks and only kill(QUIT) if the
>> current masks indicate that the JVM's signals are now being handled.
>> 
>> the behavior in the success case is now identical to the previous implementation, however should the target JVM not 
>> become "ready" (signal handlers installed) prior to the attach "timeout" occurring the attach operation will throw an
>> "AttachNotSupportedException" with a suitable error message.
>> 
>> see also: https://bugs.openjdk.org/browse/JDK-8350766
>
> Larry Cable has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'JDK-8344671' of github.com:larry-cable/jdk into JDK-8344671
>  - JDK-8334671: minor changes requested by @dholmes

Okay

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24085#pullrequestreview-2730743668