From dholmes at openjdk.org Tue Apr 1 06:03:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Apr 2025 06:03:47 GMT
Subject: RFR: 8323100: com/sun/tools/attach/StartManagementAgent.java failed
with "WaitForSingleObject failed"
Message-ID: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
See bug report for gory details.
Short version: in the Windows version of `VirtualMachineImpl::execute`, if an exception occurred after we created the `SocketInputStreamImpl` (which is the test scenario of the failing test), we would close the native `HANDLE` to the pipe twice. But after the first close the `HANDLE` could be reassigned to another object (e.g. the `_ParkHandle` of the `StreamPumper` thread) and the second close would close that `HANDLE` resulting in the failure of `WaitForSingleObject`. (Other failure modes with different invalid handles have also been seen.)
Fix: shorten the outer try/catch block so that we only directly close the pipe if the `IOException` happens before we create the `SocketStreamImpl` - after which the closing of the stream will close the pipe `HANDLE`.
Testing:
- ran the com/sun/tools/attach tets group 2500 times without failure
- tiers 3-5 as a sanity check (Windows only)
Thanks
-------------
Commit messages:
- 8323100: com/sun/tools/attach/StartManagementAgent.java failed with "WaitForSingleObject failed"
Changes: https://git.openjdk.org/jdk/pull/24346/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24346&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8323100
Stats: 26 lines in 1 file changed: 14 ins; 11 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24346.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24346/head:pull/24346
PR: https://git.openjdk.org/jdk/pull/24346
From kevinw at openjdk.org Tue Apr 1 09:11:21 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Apr 2025 09:11:21 GMT
Subject: RFR: 8323100: com/sun/tools/attach/StartManagementAgent.java
failed with "WaitForSingleObject failed"
In-Reply-To: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
References: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
Message-ID: <NcpL0gIoq337Rh3R6roIxLSVoXFnwfxtUP_0tFi1dFQ=.46d4268b-7dfd-413f-89df-ce1472323b37@github.com>
On Tue, 1 Apr 2025 05:57:55 GMT, David Holmes <dholmes at openjdk.org> wrote:
> See bug report for gory details.
>
> Short version: in the Windows version of `VirtualMachineImpl::execute`, if an exception occurred after we created the `SocketInputStreamImpl` (which is the test scenario of the failing test), we would close the native `HANDLE` to the pipe twice. But after the first close the `HANDLE` could be reassigned to another object (e.g. the `_ParkHandle` of the `StreamPumper` thread) and the second close would close that `HANDLE` resulting in the failure of `WaitForSingleObject`. (Other failure modes with different invalid handles have also been seen.)
>
> Fix: shorten the outer try/catch block so that we only directly close the pipe if the `IOException` happens before we create the `SocketStreamImpl` - after which the closing of the stream will close the pipe `HANDLE`.
>
> Testing:
> - ran the com/sun/tools/attach tets group 2500 times without failure
> - tiers 3-5 as a sanity check (Windows only)
>
> Thanks
Excellent to have this found, they just looked like an "impossible" failures. 8-)
Also good lessons in naming and commenting around processCompletionStatus.
-------------
Marked as reviewed by kevinw (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24346#pullrequestreview-2732025593
From varadam at openjdk.org Tue Apr 1 10:30:56 2025
From: varadam at openjdk.org (Varada M)
Date: Tue, 1 Apr 2025 10:30:56 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v4]
In-Reply-To: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
Message-ID: <jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@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 one additional commit since the last revision:
8352392: AIX: implement attach API v2 and streaming output
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24177/files
- new: https://git.openjdk.org/jdk/pull/24177/files/d22f0ab9..234f6d17
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24177&range=02-03
Stats: 20 lines in 2 files changed: 1 ins; 0 del; 19 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 Tue Apr 1 10:35:20 2025
From: varadam at openjdk.org (Varada M)
Date: Tue, 1 Apr 2025 10:35:20 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v3]
In-Reply-To: <ydGbLAEY5w_ctvhNUo3MRCBlLnpR_nKt_Ebl8bgt9s4=.172711d4-cc4a-4d4c-9164-519e8060b7b6@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
<4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
<ydGbLAEY5w_ctvhNUo3MRCBlLnpR_nKt_Ebl8bgt9s4=.172711d4-cc4a-4d4c-9164-519e8060b7b6@github.com>
Message-ID: <EDB1d4emrqkfwurlYqn4RlvGc9_HfKnc_Rwn-COiqG0=.ce574d75-00fd-4c14-91b8-5a187c3dccc5@github.com>
On Mon, 31 Mar 2025 10:16:31 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:
>> 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
>
> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 196:
>
>> 194: }
>> 195: }
>> 196:
>
> Same here.
Hi Martin, I have added the indentation fix and comment
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2022594632
From kevinw at openjdk.org Tue Apr 1 10:39:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 1 Apr 2025 10:39:28 GMT
Subject: RFR: 8353231: Test
com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails
intermittently
Message-ID: <PIhaXE0X5mOumCzQefIhCwiC-BZ-C3lAZPOknY0Vaac=.077220d2-7b53-47bb-aad1-0a42d0a664ba@github.com>
Test com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails intermittently.
On failure, 10 attempts with sleep(200) each time, only read -1 from mbean.getProcessCpuLoad().
The method is documented to return -1 when info is not available, but want to avoid the test accepting a -1 and masking real problems.
Test failures are happening when multiple CPU load reding tests ran on the same host, at the same second.
Add a TEST.properties file containing: exclusiveAccess.dirs=.
-------------
Commit messages:
- 8353231: Test com/sun/management/OperatingSystemMXBean cpuLoad still fails intermittently
Changes: https://git.openjdk.org/jdk/pull/24352/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24352&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353231
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24352.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24352/head:pull/24352
PR: https://git.openjdk.org/jdk/pull/24352
From ihse at openjdk.org Tue Apr 1 12:02:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 1 Apr 2025 12:02:19 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: <FNg6AZoti-zzOOqQpEpykZ6leYIL49v2efunCb2T1aw=.0d5e0f4d-03ea-453f-bc8e-9c4aaddfc846@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 .
It would be interesting to also see how compilation times varies with optimization level. At least some kind of hint if HIGHEST is like 2x slower than LOW, or if SIZE is slower than LOW at all, etc. The relative speed difference is interesting, but so is it in absolute terms. If a library takes 0.5 seconds on LOW but 1.1 seconds on HIGH on a particular system, it is unlikely to matter much to overall build time anywhere. But if it goes from 15s to 30s on a fast machine, it might be a problem if such performance regressions stack up, especially on slower machines (which includes the ones running GHA).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2769121979
From dholmes at openjdk.org Tue Apr 1 12:03:23 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 1 Apr 2025 12:03:23 GMT
Subject: RFR: 8323100: com/sun/tools/attach/StartManagementAgent.java
failed with "WaitForSingleObject failed"
In-Reply-To: <NcpL0gIoq337Rh3R6roIxLSVoXFnwfxtUP_0tFi1dFQ=.46d4268b-7dfd-413f-89df-ce1472323b37@github.com>
References: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
<NcpL0gIoq337Rh3R6roIxLSVoXFnwfxtUP_0tFi1dFQ=.46d4268b-7dfd-413f-89df-ce1472323b37@github.com>
Message-ID: <VqF-IOZxOt2QZLPA9PilTWJPnVLV47poCFULce6sIrI=.a3c534ab-1327-4597-af68-5f1b83fd5fd5@github.com>
On Tue, 1 Apr 2025 09:08:06 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> See bug report for gory details.
>>
>> Short version: in the Windows version of `VirtualMachineImpl::execute`, if an exception occurred after we created the `SocketInputStreamImpl` (which is the test scenario of the failing test), we would close the native `HANDLE` to the pipe twice. But after the first close the `HANDLE` could be reassigned to another object (e.g. the `_ParkHandle` of the `StreamPumper` thread) and the second close would close that `HANDLE` resulting in the failure of `WaitForSingleObject`. (Other failure modes with different invalid handles have also been seen.)
>>
>> Fix: shorten the outer try/catch block so that we only directly close the pipe if the `IOException` happens before we create the `SocketStreamImpl` - after which the closing of the stream will close the pipe `HANDLE`.
>>
>> Testing:
>> - ran the com/sun/tools/attach tets group 2500 times without failure
>> - tiers 3-5 as a sanity check (Windows only)
>>
>> Thanks
>
> Excellent to have this found, they just looked like an "impossible" failures. 8-)
>
> Also good lessons in naming and commenting around processCompletionStatus.
Thanks for the review @kevinjwalls !
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24346#issuecomment-2769126946
From mdoerr at openjdk.org Tue Apr 1 12:22:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Apr 2025 12:22:20 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v3]
In-Reply-To: <EDB1d4emrqkfwurlYqn4RlvGc9_HfKnc_Rwn-COiqG0=.ce574d75-00fd-4c14-91b8-5a187c3dccc5@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
<4PJ92vw13If5UwOGWdLxkM0uaUiOa4GqogzCB37xSLk=.2b0950bb-937f-408d-9c69-31dd06e391d3@github.com>
<ydGbLAEY5w_ctvhNUo3MRCBlLnpR_nKt_Ebl8bgt9s4=.172711d4-cc4a-4d4c-9164-519e8060b7b6@github.com>
<EDB1d4emrqkfwurlYqn4RlvGc9_HfKnc_Rwn-COiqG0=.ce574d75-00fd-4c14-91b8-5a187c3dccc5@github.com>
Message-ID: <LBE-WgPZh_Ry1PP1dyMQOt32LNcqog7NfWJVDqOWJV8=.557e683e-6e12-4096-9370-e6dbf5044429@github.com>
On Tue, 1 Apr 2025 10:32:55 GMT, Varada M <varadam at openjdk.org> wrote:
>> src/jdk.attach/aix/classes/sun/tools/attach/VirtualMachineImpl.java line 196:
>>
>>> 194: }
>>> 195: }
>>> 196:
>>
>> Same here.
>
> Hi Martin, I have added the indentation fix and comment
Thanks! I think it's good. Let's wait for @JoKern65 's review.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24177#discussion_r2022743745
From sgehwolf at openjdk.org Tue Apr 1 14:59:37 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 1 Apr 2025 14:59:37 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
[v17]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <ftsw92lx0y4ZTI_XZz1mgqEEKjNVB-L1G44AtJXvQM8=.cef4eac5-158a-4229-8ae5-6feae46e9f86@github.com>
> 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 44 commits:
- Merge branch 'master' into jdk-8336881-metrics-systemd-slice
- JDK-8350103
- 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
- ... and 34 more: https://git.openjdk.org/jdk/compare/6801eb87...32960cd6
-------------
Changes: https://git.openjdk.org/jdk/pull/20280/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=16
Stats: 1621 lines in 27 files changed: 1373 ins; 152 del; 96 mod
Patch: https://git.openjdk.org/jdk/pull/20280.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280
PR: https://git.openjdk.org/jdk/pull/20280
From stefank at openjdk.org Tue Apr 1 15:32:17 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 1 Apr 2025 15:32:17 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock
In-Reply-To: <h4NKslnaVrulREkzTc7CuQh_0l5QTLA100GRkfhApEk=.e71e26d2-53bc-4960-93eb-ac4afc215e39@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<h4NKslnaVrulREkzTc7CuQh_0l5QTLA100GRkfhApEk=.e71e26d2-53bc-4960-93eb-ac4afc215e39@github.com>
Message-ID: <xGjaPM672k6g0QRPLdD9XfRfeQoTffvR7-UWNFYtTK4=.a73f3818-0e4a-4d7a-86fc-2015c2b6913a@github.com>
On Mon, 31 Mar 2025 14:09:22 GMT, Robert Toyonaga <duke at openjdk.org> wrote:
> 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
Sounds like a good idea.
>
> * swapping the order of `NmtVirtualMemoryLocker` and release/uncommit
I wonder if this should be done as new RFE after the change below. It might need a bit of investigation to make sure that the reasoning around this is correct.
>
> * Fail fatally if release/uncommit does not complete.
I think this would be a good, separate RFE to be done before we try to swap the order.
>
>
> 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);
> ```
My thinking is that after you done (2) above, then you will not need to expose the NMT lock to this level. The code would be:
MemTracker::record_some_operation(addr, bytes); // Lock confined inside this
pd_unmap_memory(addr, bytes);
So, I would wait with this cleanup until we know more about (2).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2769766908
From egor.ushakov at jetbrains.com Tue Apr 1 17:14:43 2025
From: egor.ushakov at jetbrains.com (Egor Ushakov)
Date: Tue, 1 Apr 2025 19:14:43 +0200
Subject: Debugger overhead for virtual threads creation
Message-ID: <f54233ac-5a0f-463c-9917-109d4c92bc5a@jetbrains.com>
Hi everyone!
Is it expected that with the debugger attached creating virtual threads
is much slower?
We're getting bugs like: https://youtrack.jetbrains.com/issue/IDEA-365900
And I can reproduce it easily with jdb...
Just attaching the debugger immediately slows down virtual threads
creation significantly.
>java -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n,address=8000 app
...
6808805 (1.2046688E7 threads per second)
...
after >jdb -attach 8000
...
30215 (95986.055 threads per second)
...
Thanks,
Egor
From amenkov at openjdk.org Tue Apr 1 18:38:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 1 Apr 2025 18:38:33 GMT
Subject: RFR: 8323100: com/sun/tools/attach/StartManagementAgent.java
failed with "WaitForSingleObject failed"
In-Reply-To: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
References: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
Message-ID: <XOR6sUTkAHfBLvKF3MIMoqEBKPff5h0-cN7CtQgQVcc=.d6216924-bc74-4f82-9824-7260a477da49@github.com>
On Tue, 1 Apr 2025 05:57:55 GMT, David Holmes <dholmes at openjdk.org> wrote:
> See bug report for gory details.
>
> Short version: in the Windows version of `VirtualMachineImpl::execute`, if an exception occurred after we created the `SocketInputStreamImpl` (which is the test scenario of the failing test), we would close the native `HANDLE` to the pipe twice. But after the first close the `HANDLE` could be reassigned to another object (e.g. the `_ParkHandle` of the `StreamPumper` thread) and the second close would close that `HANDLE` resulting in the failure of `WaitForSingleObject`. (Other failure modes with different invalid handles have also been seen.)
>
> Fix: shorten the outer try/catch block so that we only directly close the pipe if the `IOException` happens before we create the `SocketStreamImpl` - after which the closing of the stream will close the pipe `HANDLE`.
>
> Testing:
> - ran the com/sun/tools/attach tets group 2500 times without failure
> - tiers 3-5 as a sanity check (Windows only)
>
> Thanks
Marked as reviewed by amenkov (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24346#pullrequestreview-2733724000
From cjplummer at openjdk.org Tue Apr 1 20:00:22 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 1 Apr 2025 20:00:22 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
can lock up target VM [v7]
In-Reply-To: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
Message-ID: <ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@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 update
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24236/files
- new: https://git.openjdk.org/jdk/pull/24236/files/977ecf15..80f75c60
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24236&range=06
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24236&range=05-06
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 sspitsyn at openjdk.org Tue Apr 1 20:36:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 1 Apr 2025 20:36:25 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
can lock up target VM [v7]
In-Reply-To: <ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
<ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
Message-ID: <CRnDCV-ff-Y9okTwoZq7GOOTE9UQ6Bo9d67z4ux2pqI=.e9fc67ab-c21c-4e91-81eb-43ee85ca6766@github.com>
On Tue, 1 Apr 2025 20:00:22 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:
>
> minor comment update
Marked as reviewed by sspitsyn (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2733985461
From amenkov at openjdk.org Tue Apr 1 21:32:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 1 Apr 2025 21:32:35 GMT
Subject: RFR: 8353479: jcmd with streaming output breaks intendation
Message-ID: <uhVxdPj-VacF-zO9MX4IV2wuzXINNq0qalDyswbeTxk=.02c4e7d8-7120-42a8-893c-827b900cc50e@github.com>
`outputStream` implementations should call `update_position` from `write` to correctly handle indentation.
The fix adds the call to `attachStream::write`
testing: sanity tier1;
in progress: tier2..4,hs-tier5-svc
-------------
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/24368/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24368&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353479
Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/24368.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24368/head:pull/24368
PR: https://git.openjdk.org/jdk/pull/24368
From amenkov at openjdk.org Tue Apr 1 21:32:35 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 1 Apr 2025 21:32:35 GMT
Subject: RFR: 8353479: jcmd with streaming output breaks intendation
In-Reply-To: <uhVxdPj-VacF-zO9MX4IV2wuzXINNq0qalDyswbeTxk=.02c4e7d8-7120-42a8-893c-827b900cc50e@github.com>
References: <uhVxdPj-VacF-zO9MX4IV2wuzXINNq0qalDyswbeTxk=.02c4e7d8-7120-42a8-893c-827b900cc50e@github.com>
Message-ID: <GdBqvJtESiXxTxLhi-LSSi6SR9huLuqpUr2nbkkiEUA=.89a846f5-783a-4376-9a52-3ed8387329d0@github.com>
On Tue, 1 Apr 2025 21:23:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
> `outputStream` implementations should call `update_position` from `write` to correctly handle indentation.
> The fix adds the call to `attachStream::write`
>
> testing: sanity tier1;
> in progress: tier2..4,hs-tier5-svc
Example of output with and without streaming output:
$ JAVA_TOOL_OPTIONS=-Djdk.attach.allowStreamingOutput=true jcmd 31544 VM.native_memory
Picked up JAVA_TOOL_OPTIONS: -Djdk.attach.allowStreamingOutput=true
31544:
Native Memory Tracking:
(Omitting categories weighting less than 1KB)
Total: reserved=9953148KB, committed=407888KB
malloc: 57776KB #293244, peak=75433KB #212390
mmap: reserved=9895372KB, committed=350112KB
- Java Heap (reserved=8298496KB, committed=270336KB)
(mmap: reserved=8298496KB, committed=270336KB, peak=520192KB)
- Class (reserved=1048938KB, committed=2922KB)
(classes #3716)
( instance classes #3406, array classes #310)
(malloc=362KB #7060 ) (peak=364KB #7068)
(mmap: reserved=1048576KB, committed=2560KB, at peak)
( Metadata: )
( reserved=65536KB, committed=24384KB )
( used=24223KB)
( waste=161KB =0.66%)
( Class space:)
( reserved=1048576KB, committed=2560KB )
( used=2423KB)
( waste=137KB =5.36%)
$ jcmd 31544 VM.native_memory
31544:
Native Memory Tracking:
(Omitting categories weighting less than 1KB)
Total: reserved=9953152KB, committed=407892KB
malloc: 57780KB #293282, peak=75433KB #212390
mmap: reserved=9895372KB, committed=350112KB
- Java Heap (reserved=8298496KB, committed=270336KB)
(mmap: reserved=8298496KB, committed=270336KB, peak=520192KB)
- Class (reserved=1048938KB, committed=2922KB)
(classes #3716)
( instance classes #3406, array classes #310)
(malloc=362KB #7060) (peak=364KB #7068)
(mmap: reserved=1048576KB, committed=2560KB, at peak)
( Metadata: )
( reserved=65536KB, committed=24384KB)
( used=24223KB)
( waste=161KB =0.66%)
( Class space:)
( reserved=1048576KB, committed=2560KB)
( used=2423KB)
( waste=137KB =5.36%)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24368#issuecomment-2770724520
From chris.plummer at oracle.com Tue Apr 1 23:39:07 2025
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 1 Apr 2025 16:39:07 -0700
Subject: Debugger overhead for virtual threads creation
In-Reply-To: <f54233ac-5a0f-463c-9917-109d4c92bc5a@jetbrains.com>
References: <f54233ac-5a0f-463c-9917-109d4c92bc5a@jetbrains.com>
Message-ID: <c249df7f-9cc1-46f2-b08d-bdf48cf5770e@oracle.com>
The short answer is yes. The debug agent needs to deal with
JVMTI_EVENT_VIRTUAL_THREAD_START/END events for every virtual thread.
What makes it worse is when there are a large number of virtual threads
that are currently alive. They are tracked on a list of ThreadNodes that
starts to slow down debug agent performance when it gets too long. I
have a work in progress that proactively purges these ThreadNodes so the
list does not get too big.?I've been meaning to revive this project for
quite some time. If you have a test case I'd be willing to experiment
with these changes some more. I could not access to the IDEA-365900 link
you provided.
Note I think after the work is done to purge ThreadNodes proactively it
might not be that hard of step to move to not needing
JVMTI_EVENT_VIRTUAL_THREAD_START/END events enabled, which will help
performance a lot more.
Chris
On 4/1/25 10:14 AM, Egor Ushakov wrote:
> Hi everyone!
>
> Is it expected that with the debugger attached creating virtual
> threads is much slower?
> We're getting bugs like: https://youtrack.jetbrains.com/issue/IDEA-365900
> And I can reproduce it easily with jdb...
> Just attaching the debugger immediately slows down virtual threads
> creation significantly.
>
> >java
> -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n,address=8000 app
> ...
> 6808805 (1.2046688E7 threads per second)
> ...
> after >jdb -attach 8000
> ...
> 30215 (95986.055 threads per second)
> ...
>
> Thanks,
> Egor
From jpai at openjdk.org Wed Apr 2 01:40:31 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 2 Apr 2025 01:40:31 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
can lock up target VM [v7]
In-Reply-To: <ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
<ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
Message-ID: <5kETU88L5YqVVQgMSB7QDo8heC9-R4Ia_JhXt2ZkfVQ=.2ce9a39e-ad21-433d-b724-de1ceb3336f5@github.com>
On Tue, 1 Apr 2025 20:00:22 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:
>
> minor comment update
Marked as reviewed by jpai (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2734354863
From dholmes at openjdk.org Wed Apr 2 03:00:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Apr 2025 03:00:17 GMT
Subject: RFR: 8323100: com/sun/tools/attach/StartManagementAgent.java
failed with "WaitForSingleObject failed"
In-Reply-To: <XOR6sUTkAHfBLvKF3MIMoqEBKPff5h0-cN7CtQgQVcc=.d6216924-bc74-4f82-9824-7260a477da49@github.com>
References: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
<XOR6sUTkAHfBLvKF3MIMoqEBKPff5h0-cN7CtQgQVcc=.d6216924-bc74-4f82-9824-7260a477da49@github.com>
Message-ID: <BNwTuPFsu8Fa3Isa6m27CMTYeWr4yU7H3_VKEM3LHNc=.66cbf4a3-aedd-4146-98d6-8e1ca52d30ea@github.com>
On Tue, 1 Apr 2025 18:35:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
>> See bug report for gory details.
>>
>> Short version: in the Windows version of `VirtualMachineImpl::execute`, if an exception occurred after we created the `SocketInputStreamImpl` (which is the test scenario of the failing test), we would close the native `HANDLE` to the pipe twice. But after the first close the `HANDLE` could be reassigned to another object (e.g. the `_ParkHandle` of the `StreamPumper` thread) and the second close would close that `HANDLE` resulting in the failure of `WaitForSingleObject`. (Other failure modes with different invalid handles have also been seen.)
>>
>> Fix: shorten the outer try/catch block so that we only directly close the pipe if the `IOException` happens before we create the `SocketStreamImpl` - after which the closing of the stream will close the pipe `HANDLE`.
>>
>> Testing:
>> - ran the com/sun/tools/attach tets group 2500 times without failure
>> - tiers 3-5 as a sanity check (Windows only)
>>
>> Thanks
>
> Marked as reviewed by amenkov (Reviewer).
Thanks for the review @alexmenkov !
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24346#issuecomment-2771215407
From dholmes at openjdk.org Wed Apr 2 03:00:18 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 2 Apr 2025 03:00:18 GMT
Subject: Integrated: 8323100: com/sun/tools/attach/StartManagementAgent.java
failed with "WaitForSingleObject failed"
In-Reply-To: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
References: <Nmo7oVQKkLWI2jEIVCelzEVWBIksjKOJfNVSQDpq428=.40e94efc-d4b8-461c-bf58-fbc1158d88b3@github.com>
Message-ID: <6XUN6YuzWuA_WbJMP4CzRUyfFJr3aeozRTUcXJe1pFo=.451b7623-8873-4d35-a826-1c22665f39db@github.com>
On Tue, 1 Apr 2025 05:57:55 GMT, David Holmes <dholmes at openjdk.org> wrote:
> See bug report for gory details.
>
> Short version: in the Windows version of `VirtualMachineImpl::execute`, if an exception occurred after we created the `SocketInputStreamImpl` (which is the test scenario of the failing test), we would close the native `HANDLE` to the pipe twice. But after the first close the `HANDLE` could be reassigned to another object (e.g. the `_ParkHandle` of the `StreamPumper` thread) and the second close would close that `HANDLE` resulting in the failure of `WaitForSingleObject`. (Other failure modes with different invalid handles have also been seen.)
>
> Fix: shorten the outer try/catch block so that we only directly close the pipe if the `IOException` happens before we create the `SocketStreamImpl` - after which the closing of the stream will close the pipe `HANDLE`.
>
> Testing:
> - ran the com/sun/tools/attach tets group 2500 times without failure
> - tiers 3-5 as a sanity check (Windows only)
>
> Thanks
This pull request has now been integrated.
Changeset: e6fe2490
Author: David Holmes <dholmes at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/e6fe2490bc48acf01ccf81b38d578d20ed09f238
Stats: 26 lines in 1 file changed: 14 ins; 11 del; 1 mod
8323100: com/sun/tools/attach/StartManagementAgent.java failed with "WaitForSingleObject failed"
Reviewed-by: kevinw, amenkov
-------------
PR: https://git.openjdk.org/jdk/pull/24346
From alanb at openjdk.org Wed Apr 2 06:13:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Apr 2025 06:13:11 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
can lock up target VM [v7]
In-Reply-To: <ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
<ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
Message-ID: <Xwfbn_kGnbUKs5eUUJICW_Q1RET4LuqKPEEGdtysWk0=.16ff1b78-331f-4c3a-bc59-a2f78622482b@github.com>
On Tue, 1 Apr 2025 20:00:22 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:
>
> minor comment update
Marked as reviewed by alanb (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24236#pullrequestreview-2734755558
From sspitsyn at openjdk.org Wed Apr 2 08:37:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 2 Apr 2025 08:37:22 GMT
Subject: RFR: 8353479: jcmd with streaming output breaks intendation
In-Reply-To: <uhVxdPj-VacF-zO9MX4IV2wuzXINNq0qalDyswbeTxk=.02c4e7d8-7120-42a8-893c-827b900cc50e@github.com>
References: <uhVxdPj-VacF-zO9MX4IV2wuzXINNq0qalDyswbeTxk=.02c4e7d8-7120-42a8-893c-827b900cc50e@github.com>
Message-ID: <284gTOn3RoFPKIgLIzsrEPF5KGoJ2Ci98oW2pb9o7nU=.7a6d5b14-a058-4f51-8693-571c07d05d1d@github.com>
On Tue, 1 Apr 2025 21:23:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
> `outputStream` implementations should call `update_position` from `write` to correctly handle indentation.
> The fix adds the call to `attachStream::write`
>
> testing: sanity tier1;
> in progress: tier2..4,hs-tier5-svc
Looks okay to me.
-------------
Marked as reviewed by sspitsyn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24368#pullrequestreview-2735241312
From kevinw at openjdk.org Wed Apr 2 08:43:22 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 2 Apr 2025 08:43:22 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: <KeoVZVbhMUh0UhjxruA6zcBeo63SDIOH-OUE1722PAc=.3a126af9-1b13-46ad-9b9e-9b2a4c5abb08@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
Looks good.
(I'm sure the Linux and MacOS VirtualMachineImpl() attach/timeout loops are almost identical now, not a problem but maybe one day we can de-duplicate them.)
-------------
Marked as reviewed by kevinw (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24085#pullrequestreview-2735291287
From egor.ushakov at jetbrains.com Wed Apr 2 10:32:03 2025
From: egor.ushakov at jetbrains.com (Egor Ushakov)
Date: Wed, 2 Apr 2025 12:32:03 +0200
Subject: Debugger overhead for virtual threads creation
In-Reply-To: <c249df7f-9cc1-46f2-b08d-bdf48cf5770e@oracle.com>
References: <f54233ac-5a0f-463c-9917-109d4c92bc5a@jetbrains.com>
<c249df7f-9cc1-46f2-b08d-bdf48cf5770e@oracle.com>
Message-ID: <5451248a-ded9-4b57-bc4d-23c336adca0f@jetbrains.com>
Thanks Chris!
I've made the bug?https://youtrack.jetbrains.com/issue/IDEA-365900
visible, there's a reproducer there.
Thanks,
Egor
On 02.04.2025 01:39, Chris Plummer wrote:
> The short answer is yes. The debug agent needs to deal with
> JVMTI_EVENT_VIRTUAL_THREAD_START/END events for every virtual thread.
> What makes it worse is when there are a large number of virtual
> threads that are currently alive. They are tracked on a list of
> ThreadNodes that starts to slow down debug agent performance when it
> gets too long. I have a work in progress that proactively purges these
> ThreadNodes so the list does not get too big.?I've been meaning to
> revive this project for quite some time. If you have a test case I'd
> be willing to experiment with these changes some more. I could not
> access to the IDEA-365900 link you provided.
>
> Note I think after the work is done to purge ThreadNodes proactively
> it might not be that hard of step to move to not needing
> JVMTI_EVENT_VIRTUAL_THREAD_START/END events enabled, which will help
> performance a lot more.
>
> Chris
>
> On 4/1/25 10:14 AM, Egor Ushakov wrote:
>> Hi everyone!
>>
>> Is it expected that with the debugger attached creating virtual
>> threads is much slower?
>> We're getting bugs like:
>> https://youtrack.jetbrains.com/issue/IDEA-365900
>> And I can reproduce it easily with jdb...
>> Just attaching the debugger immediately slows down virtual threads
>> creation significantly.
>>
>> >java
>> -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n,address=8000 app
>> ...
>> 6808805 (1.2046688E7 threads per second)
>> ...
>> after >jdb -attach 8000
>> ...
>> 30215 (95986.055 threads per second)
>> ...
>>
>> Thanks,
>> Egor
From jkern at openjdk.org Wed Apr 2 11:05:01 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 2 Apr 2025 11:05:01 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v4]
In-Reply-To: <jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
<jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
Message-ID: <dmM70I8uh0uLbnw45ExapkwuD8W-ze7_RRppuiJQyjY=.3e07b29a-9cca-4c2d-89dc-4bb8c3d6b557@github.com>
On Tue, 1 Apr 2025 10:30:56 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 one additional commit since the last revision:
>
> 8352392: AIX: implement attach API v2 and streaming output
Hi Varada, I see that you've largely adapted the code to the POSIX version. Essentially, only the shutdown special handling remains. But the AIX special handling that you removed was introduced for some reason.
Do you know why? Does this reasoning no longer apply?
I have no idea and can't judge whether the different semantics have created holes in the code that could reappear under certain circumstances.
Therefore, I would like an explanation from you as to why you can make this change now.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2772207203
From jsjolen at openjdk.org Wed Apr 2 12:45:59 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 2 Apr 2025 12:45:59 GMT
Subject: RFR: 8353479: jcmd with streaming output breaks intendation
In-Reply-To: <uhVxdPj-VacF-zO9MX4IV2wuzXINNq0qalDyswbeTxk=.02c4e7d8-7120-42a8-893c-827b900cc50e@github.com>
References: <uhVxdPj-VacF-zO9MX4IV2wuzXINNq0qalDyswbeTxk=.02c4e7d8-7120-42a8-893c-827b900cc50e@github.com>
Message-ID: <cpVgCPqYJJY3xcNqmVDNbMbUS57Fw7JDj765Y73HuFU=.d3ac497a-327f-41e5-ae06-2db199504b13@github.com>
On Tue, 1 Apr 2025 21:23:01 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
> `outputStream` implementations should call `update_position` from `write` to correctly handle indentation.
> The fix adds the call to `attachStream::write`
>
> testing: sanity tier1;
> in progress: tier2..4,hs-tier5-svc
Thanks!
-------------
Marked as reviewed by jsjolen (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24368#pullrequestreview-2736139795
From duke at openjdk.org Wed Apr 2 14:02:25 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 2 Apr 2025 14:02:25 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v2]
In-Reply-To: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
Message-ID: <krK7TQLRUg-VggNMd_wH4gJZ-zpF_cSjuHCGbBZDWv4=.1950f023-5905-4420-9a3c-8183cc3982af@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 call...
Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
- tests and comments
- Revert "make memory op and NMT accounting atomic"
This reverts commit 86423d0b7e8e2b0b313a686a64c803028a5f2420.
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24084/files
- new: https://git.openjdk.org/jdk/pull/24084/files/86423d0b..74f31202
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=00-01
Stats: 246 lines in 12 files changed: 60 ins; 123 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 duke at openjdk.org Wed Apr 2 14:06:09 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 2 Apr 2025 14:06:09 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v2]
In-Reply-To: <krK7TQLRUg-VggNMd_wH4gJZ-zpF_cSjuHCGbBZDWv4=.1950f023-5905-4420-9a3c-8183cc3982af@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<krK7TQLRUg-VggNMd_wH4gJZ-zpF_cSjuHCGbBZDWv4=.1950f023-5905-4420-9a3c-8183cc3982af@github.com>
Message-ID: <YANBozDekd1sRc7hcNOdOvx8WrghLUWfVtV1dAAWuVA=.f5473085-eccb-42bc-8717-8b3b013ae9e7@github.com>
On Wed, 2 Apr 2025 14:02:25 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 i...
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
>
> - tests and comments
> - Revert "make memory op and NMT accounting atomic"
>
> This reverts commit 86423d0b7e8e2b0b313a686a64c803028a5f2420.
OK I have reverted the original changes, added comments, and kept the new tests that are still relevant. Please have another look when you have time. I'll go ahead and open RFE's for the topics you suggested above.
Thanks!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2772669368
From duke at openjdk.org Wed Apr 2 16:03:04 2025
From: duke at openjdk.org (Larry Cable)
Date: Wed, 2 Apr 2025 16:03:04 GMT
Subject: Integrated: 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: <tuuPORq9yFl32DhkjsOYdjm6Pad4bEZD3bpttTK1dS8=.43bec0df-43f3-4932-b422-1a59d8887543@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
This pull request has now been integrated.
Changeset: d979bd85
Author: Larry Cable <larry.cable at yahoo.com>
Committer: Kevin Walls <kevinw at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/d979bd859215a16e6398ae627acfd40e8d71102c
Stats: 60 lines in 3 files changed: 44 ins; 3 del; 13 mod
8344671: Few JFR streaming tests fail with application not alive error on MacOS 15
Reviewed-by: dholmes, kevinw
-------------
PR: https://git.openjdk.org/jdk/pull/24085
From cjplummer at openjdk.org Wed Apr 2 17:07:02 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 2 Apr 2025 17:07:02 GMT
Subject: RFR: 8352088: Call of com.sun.jdi.ThreadReference.threadGroups()
can lock up target VM [v7]
In-Reply-To: <ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
References: <alumHRJZp-y56mSOh9dsKJ6mPWEw5xUuBxFuxLPJLyg=.3042e804-c8bf-4d1e-842f-0d0f5c91ff56@github.com>
<ilau5GWhGXyp72rj8pgBFEC5wuZ102fwSkjBKMNpp5U=.392710a1-60d3-4a99-9c93-77f0378fce4d@github.com>
Message-ID: <ilUgY2-jWThAxIaB1xBXR3yKLOASLgGGHtKudRL_PLA=.a009169e-6c28-4d4d-acba-5a0e64680567@github.com>
On Tue, 1 Apr 2025 20:00:22 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:
>
> minor comment update
Thanks reviews Sergei, Jai, and Alan
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24236#issuecomment-2773202187
From cjplummer at openjdk.org Wed Apr 2 17:07:03 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 2 Apr 2025 17:07:03 GMT
Subject: Integrated: 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: <dgvMdm51ch-u5xtrGEQ9sHqAxkGk_agFeb_d5n7i1ck=.1a6ca952-1a77-41e4-98a6-324f8f80242d@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.
This pull request has now been integrated.
Changeset: cc870d49
Author: Chris Plummer <cjplummer at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/cc870d4960b3e121afc76df546228cda4b600632
Stats: 130 lines in 2 files changed: 128 ins; 0 del; 2 mod
8352088: Call of com.sun.jdi.ThreadReference.threadGroups() can lock up target VM
Reviewed-by: alanb, jpai, sspitsyn
-------------
PR: https://git.openjdk.org/jdk/pull/24236
From duke at openjdk.org Thu Apr 3 02:56:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 3 Apr 2025 02:56:54 GMT
Subject: Withdrawn: 8336017: Deprecate java.util.logging.LoggingMXBean,
its implementation, and accessor method for removal
In-Reply-To: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
References: <bFTE1F473y7graKpGR0CQ-clA43Af9p7H2Ixs105j6I=.951c9640-e98f-43f0-8943-42771924dc13@github.com>
Message-ID: <J67xFx1oJYJ-mJt43b_raKYXrr8NcdA19BGht3rQ1vg=.a9f85d6d-74dd-4d53-a29f-c63794edb162@github.com>
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> java.util.logging.LoggingMXBean and java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for future removal.
>
> java.util.logging.Logging (implements LoggingMXBean) should also be deprecated for removal.
This pull request has been closed without being integrated.
-------------
PR: https://git.openjdk.org/jdk/pull/23271
From iklam at openjdk.org Thu Apr 3 04:09:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Apr 2025 04:09:28 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output
Message-ID: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
const char* CDSConfig::input_static_archive_path();
const char* CDSConfig::input_dynamic_archive_path();
const char* CDSConfig::output_archive_path();
This PR also cleans up the code by:
- renaming a few function to reflect what they actually do
- moving more "config" management code into cdsConfig.cpp
There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
-------------
Depends on: https://git.openjdk.org/jdk/pull/24272
Commit messages:
- Minimized changes in ergo_init_classic_archive_paths()
- Clean up CDS input/output path handling
Changes: https://git.openjdk.org/jdk/pull/24401/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353597
Stats: 304 lines in 15 files changed: 156 ins; 55 del; 93 mod
Patch: https://git.openjdk.org/jdk/pull/24401.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401
PR: https://git.openjdk.org/jdk/pull/24401
From iklam at openjdk.org Thu Apr 3 04:09:29 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Apr 2025 04:09:29 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output
In-Reply-To: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
Message-ID: <RhmME3dtvfdwpoDEUqFr2O8lYeUAI46UzoXNGnvQ1qA=.07c28ece-fb92-4f3a-bae4-72131edc573b@github.com>
On Thu, 3 Apr 2025 04:00:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>
> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>
>
> const char* CDSConfig::input_static_archive_path();
> const char* CDSConfig::input_dynamic_archive_path();
> const char* CDSConfig::output_archive_path();
>
>
> This PR also cleans up the code by:
> - renaming a few function to reflect what they actually do
> - moving more "config" management code into cdsConfig.cpp
>
> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>
> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
src/hotspot/share/cds/dynamicArchive.cpp line 499:
> 497: }
> 498: }
> 499:
Moved to `CDSConfig::prepare_for_dumping()`
src/hotspot/share/cds/metaspaceShared.cpp line 795:
> 793: assert(CDSConfig::is_dumping_archive(), "sanity");
> 794: CDSConfig::check_unsupported_dumping_module_options();
> 795: }
Moved to `CDSConfig::prepare_for_dumping()`
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2026141716
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2026142127
From varadam at openjdk.org Thu Apr 3 07:23:05 2025
From: varadam at openjdk.org (Varada M)
Date: Thu, 3 Apr 2025 07:23:05 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v4]
In-Reply-To: <jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
<jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
Message-ID: <FWQ5uniNpt4IlVLh1ner_X6srIb9d4ebkmDTVPnlr04=.c7263dd8-a876-405f-ad5b-d024ee97ecc5@github.com>
On Tue, 1 Apr 2025 10:30:56 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 one additional commit since the last revision:
>
> 8352392: AIX: implement attach API v2 and streaming output
With the Attach API protocol update to version 2, now support arbitrary-length arguments, and shared code has been added in attachListener.cpp ([read_request](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/services/attachListener.cpp#L845), [write_fully](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/services/attachListener.cpp#L908)) to handle this across platforms. As a result, the AIX code is no longer required. I also compared the older changes in the POSIX implementation and found them to be the same as AIX
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2774714653
From serguei.spitsyn at oracle.com Thu Apr 3 09:15:15 2025
From: serguei.spitsyn at oracle.com (Serguei Spitsyn)
Date: Thu, 3 Apr 2025 09:15:15 +0000
Subject: Debugger overhead for virtual threads creation
In-Reply-To: <5451248a-ded9-4b57-bc4d-23c336adca0f@jetbrains.com>
References: <f54233ac-5a0f-463c-9917-109d4c92bc5a@jetbrains.com>
<c249df7f-9cc1-46f2-b08d-bdf48cf5770e@oracle.com>
<5451248a-ded9-4b57-bc4d-23c336adca0f@jetbrains.com>
Message-ID: <CH2PR10MB43251C8336A7CEB86B4FB17A8DAE2@CH2PR10MB4325.namprd10.prod.outlook.com>
Hi Egor,
Thank you for reporting this scalability issue when debugger is enabled.
It looks like a JVMTI problem and we have some guesses but need some investigation to identify it better.
Thanks,
Serguei
From: serviceability-dev <serviceability-dev-retn at openjdk.org> on behalf of Egor Ushakov <egor.ushakov at jetbrains.com>
Date: Wednesday, April 2, 2025 at 3:32?AM
To: Chris Plummer <chris.plummer at oracle.com>, serviceability-dev <serviceability-dev at openjdk.java.net>
Subject: Re: Debugger overhead for virtual threads creation
Thanks Chris!
I've made the bug https://youtrack.jetbrains.com/issue/IDEA-365900
visible, there's a reproducer there.
Thanks,
Egor
On 02.04.2025 01:39, Chris Plummer wrote:
> The short answer is yes. The debug agent needs to deal with
> JVMTI_EVENT_VIRTUAL_THREAD_START/END events for every virtual thread.
> What makes it worse is when there are a large number of virtual
> threads that are currently alive. They are tracked on a list of
> ThreadNodes that starts to slow down debug agent performance when it
> gets too long. I have a work in progress that proactively purges these
> ThreadNodes so the list does not get too big. I've been meaning to
> revive this project for quite some time. If you have a test case I'd
> be willing to experiment with these changes some more. I could not
> access to the IDEA-365900 link you provided.
>
> Note I think after the work is done to purge ThreadNodes proactively
> it might not be that hard of step to move to not needing
> JVMTI_EVENT_VIRTUAL_THREAD_START/END events enabled, which will help
> performance a lot more.
>
> Chris
>
> On 4/1/25 10:14 AM, Egor Ushakov wrote:
>> Hi everyone!
>>
>> Is it expected that with the debugger attached creating virtual
>> threads is much slower?
>> We're getting bugs like:
>> https://youtrack.jetbrains.com/issue/IDEA-365900
>> And I can reproduce it easily with jdb...
>> Just attaching the debugger immediately slows down virtual threads
>> creation significantly.
>>
>> >java
>> -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n,address=8000 app
>> ...
>> 6808805 (1.2046688E7 threads per second)
>> ...
>> after >jdb -attach 8000
>> ...
>> 30215 (95986.055 threads per second)
>> ...
>>
>> Thanks,
>> Egor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250403/47c30c14/attachment-0001.htm>
From jkern at openjdk.org Thu Apr 3 10:23:55 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 3 Apr 2025 10:23:55 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v2]
In-Reply-To: <krK7TQLRUg-VggNMd_wH4gJZ-zpF_cSjuHCGbBZDWv4=.1950f023-5905-4420-9a3c-8183cc3982af@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<krK7TQLRUg-VggNMd_wH4gJZ-zpF_cSjuHCGbBZDWv4=.1950f023-5905-4420-9a3c-8183cc3982af@github.com>
Message-ID: <wr2V03e45LWBbm1DoCwc1H7jYLXRElY-YIzjhwDajH4=.50defdd0-bcf8-4028-8fa0-2b0b8eef9d8d@github.com>
On Wed, 2 Apr 2025 14:02:25 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 i...
>
> Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision:
>
> - tests and comments
> - Revert "make memory op and NMT accounting atomic"
>
> This reverts commit 86423d0b7e8e2b0b313a686a64c803028a5f2420.
Tonight we tested this PR on AIX and it failed in the gtest with
Internal Error (os_aix.cpp:1917), pid=26476938, tid=258
Error: guarantee((vmi)) failed
This will happen if a
`os::pd_commit_memory()` or `os::pd_release_memory()` or `os::pd_uncommit_memory()`
is called on memory not allocated with
`os::pd_reserve_memory()` or `os::pd_attempt_map_memory_to_file_at()` or `os::pd_attempt_reserve_memory_at()`
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2775248289
From jkern at openjdk.org Thu Apr 3 12:50:57 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Thu, 3 Apr 2025 12:50:57 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v4]
In-Reply-To: <jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
<jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
Message-ID: <-x81ydaT2ImEfbGOLisk3XiQDsbln91IUf3jDNA1NDk=.d035465a-cb77-4c88-99aa-f7fc171411d0@github.com>
On Tue, 1 Apr 2025 10:30:56 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 one additional commit since the last revision:
>
> 8352392: AIX: implement attach API v2 and streaming output
Reasonable change.
-------------
Marked as reviewed by jkern (Committer).
PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2739729179
From mdoerr at openjdk.org Thu Apr 3 14:48:01 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 3 Apr 2025 14:48:01 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v4]
In-Reply-To: <jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
<jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
Message-ID: <ZqtMNfoolJr-qK6RiDC0Lnf0EQD6muV1rjtGIISvaqg=.08152693-fb02-4874-b6e5-44e7628009e1@github.com>
On Tue, 1 Apr 2025 10:30:56 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 one additional commit since the last revision:
>
> 8352392: AIX: implement attach API v2 and streaming output
Marked as reviewed by mdoerr (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24177#pullrequestreview-2740165191
From duke at openjdk.org Thu Apr 3 15:27:15 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 3 Apr 2025 15:27:15 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v3]
In-Reply-To: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
Message-ID: <pENA7rNLFax4lrCdieDSNxFQ58RsHjmCkj2UWFb0tTo=.87bb0fc6-1cd4-49ad-9ce0-170273fbd8e8@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 call...
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
exclude file mapping tests on AIX.
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24084/files
- new: https://git.openjdk.org/jdk/pull/24084/files/74f31202..5c23a76a
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=01-02
Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 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 duke at openjdk.org Thu Apr 3 15:27:16 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 3 Apr 2025 15:27:16 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v2]
In-Reply-To: <wr2V03e45LWBbm1DoCwc1H7jYLXRElY-YIzjhwDajH4=.50defdd0-bcf8-4028-8fa0-2b0b8eef9d8d@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<krK7TQLRUg-VggNMd_wH4gJZ-zpF_cSjuHCGbBZDWv4=.1950f023-5905-4420-9a3c-8183cc3982af@github.com>
<wr2V03e45LWBbm1DoCwc1H7jYLXRElY-YIzjhwDajH4=.50defdd0-bcf8-4028-8fa0-2b0b8eef9d8d@github.com>
Message-ID: <flDDr9jGqBNgvWo0TSDhcDOY6_YZuFD5DNxaJogdcrU=.5cb857a2-a0cd-435c-90cd-85f4d29d6248@github.com>
On Thu, 3 Apr 2025 10:21:29 GMT, Joachim Kern <jkern at openjdk.org> wrote:
> Internal Error (os_aix.cpp:1917), pid=26476938, tid=258 Error: guarantee((vmi)) failed
>
> This will happen if a `os::pd_commit_memory()` or `os::pd_release_memory()` or `os::pd_uncommit_memory()` is called on memory not allocated with `os::pd_reserve_memory()` or `os::pd_attempt_map_memory_to_file_at()` or `os::pd_attempt_reserve_memory_at()`
Thank you for running the tests on AIX. I've excluded the file mapping tests that don't meet that criteria on AIX.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2776162180
From iklam at openjdk.org Thu Apr 3 15:46:31 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Apr 2025 15:46:31 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v2]
In-Reply-To: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
Message-ID: <gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>
> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>
>
> const char* CDSConfig::input_static_archive_path();
> const char* CDSConfig::input_dynamic_archive_path();
> const char* CDSConfig::output_archive_path();
>
>
> This PR also cleans up the code by:
> - renaming a few function to reflect what they actually do
> - moving more "config" management code into cdsConfig.cpp
>
> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>
> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
more clean up
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24401/files
- new: https://git.openjdk.org/jdk/pull/24401/files/9e17fedb..3ad42a3e
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=00-01
Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
Patch: https://git.openjdk.org/jdk/pull/24401.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401
PR: https://git.openjdk.org/jdk/pull/24401
From lmesnik at openjdk.org Thu Apr 3 19:36:55 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 3 Apr 2025 19:36:55 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v2]
In-Reply-To: <gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
Message-ID: <dK9GtrRADdKtBLFcFjALdk3TdDZ0YJnENHmUCbgt_bI=.57118b11-7dc0-4d93-b02a-b110e1e745d1@github.com>
On Thu, 3 Apr 2025 15:46:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>>
>> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>>
>>
>> const char* CDSConfig::input_static_archive_path();
>> const char* CDSConfig::input_dynamic_archive_path();
>> const char* CDSConfig::output_archive_path();
>>
>>
>> This PR also cleans up the code by:
>> - renaming a few function to reflect what they actually do
>> - moving more "config" management code into cdsConfig.cpp
>>
>> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>>
>> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>
> more clean up
Changes requested by lmesnik (Reviewer).
test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java line 28:
> 26: * @test
> 27: * @summary "AOT" aliases for traditional CDS command-line options
> 28: * @requires vm.cds & vm.compMode != "Xcomp"
The test completely ignore external VM flags, so it should have
`@requires vm.flagless `
and no Xcomp exclusion is required.
-------------
PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2740946504
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2027621201
From iklam at openjdk.org Thu Apr 3 20:31:50 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Apr 2025 20:31:50 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v3]
In-Reply-To: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
Message-ID: <OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>
> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>
>
> const char* CDSConfig::input_static_archive_path();
> const char* CDSConfig::input_dynamic_archive_path();
> const char* CDSConfig::output_archive_path();
>
>
> This PR also cleans up the code by:
> - renaming a few function to reflect what they actually do
> - moving more "config" management code into cdsConfig.cpp
>
> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>
> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
@lmesnik comments
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24401/files
- new: https://git.openjdk.org/jdk/pull/24401/files/3ad42a3e..90b4b688
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=01-02
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24401.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401
PR: https://git.openjdk.org/jdk/pull/24401
From chris.plummer at oracle.com Thu Apr 3 20:32:50 2025
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 3 Apr 2025 13:32:50 -0700
Subject: Debugger overhead for virtual threads creation
In-Reply-To: <CH2PR10MB43251C8336A7CEB86B4FB17A8DAE2@CH2PR10MB4325.namprd10.prod.outlook.com>
References: <f54233ac-5a0f-463c-9917-109d4c92bc5a@jetbrains.com>
<c249df7f-9cc1-46f2-b08d-bdf48cf5770e@oracle.com>
<5451248a-ded9-4b57-bc4d-23c336adca0f@jetbrains.com>
<CH2PR10MB43251C8336A7CEB86B4FB17A8DAE2@CH2PR10MB4325.namprd10.prod.outlook.com>
Message-ID: <3ade7875-b4c8-4bf0-82cf-71452caf8df1@oracle.com>
I got my prototype ThreadNode cleanup code working again. It seems to be
doing the job of keeping the list down to a minimal size, with usually
at most a few ThreadNodes on the list. However, that didn't help
performance. The reason is because the debug agent normally does not
need to traverse the list. It maps jthread to ThreadNode by using JVMTI
thread local data, not by searching the list, and the list is doubly
linked, so ThreadNodes can be removed quickly.
After the above results I talked with Serguei and he confirmed that
JVMTI also has a linked list, and there are some occasions where it
needs to be traversed, so that likely the bottleneck here.
Regarding my suggestion that we may be able to disable
JVMTI_EVENT_VIRTUAL_THREAD_START/END, I did experiment with that and
when disabled there are no performance issues, so I will look into
getting this to work properly. The events need to be enable if there are
any ThreadStartRequests or ThreadDeathRequests that do not have the
PlatformThreadOnly filter enabled.
https://docs.oracle.com/en/java/javase/24/docs/api/jdk.jdi/com/sun/jdi/request/ThreadStartRequest.html#addPlatformThreadsOnlyFilter()
Jdb by default uses this filter, and I suspect that IDEA does also. If
not, it would get a flood of ThreadStart and ThreadDeath events for all
the virtual threads.
Chris
On 4/3/25 2:15 AM, Serguei Spitsyn wrote:
>
> Hi Egor,
>
> Thank you for reporting this scalability issue when debugger is enabled.
> It looks like a JVMTI problem and we have some guesses but need some
> investigation to identify it better.
>
> Thanks,
>
> Serguei
>
> *From: *serviceability-dev <serviceability-dev-retn at openjdk.org> on
> behalf of Egor Ushakov <egor.ushakov at jetbrains.com>
> *Date: *Wednesday, April 2, 2025 at 3:32?AM
> *To: *Chris Plummer <chris.plummer at oracle.com>, serviceability-dev
> <serviceability-dev at openjdk.java.net>
> *Subject: *Re: Debugger overhead for virtual threads creation
>
> Thanks Chris!
>
> I've made the bug https://youtrack.jetbrains.com/issue/IDEA-365900
> visible, there's a reproducer there.
>
> Thanks,
> Egor
>
> On 02.04.2025 01:39, Chris Plummer wrote:
> > The short answer is yes. The debug agent needs to deal with
> > JVMTI_EVENT_VIRTUAL_THREAD_START/END events for every virtual thread.
> > What makes it worse is when there are a large number of virtual
> > threads that are currently alive. They are tracked on a list of
> > ThreadNodes that starts to slow down debug agent performance when it
> > gets too long. I have a work in progress that proactively purges these
> > ThreadNodes so the list does not get too big.?I've been meaning to
> > revive this project for quite some time. If you have a test case I'd
> > be willing to experiment with these changes some more. I could not
> > access to the IDEA-365900 link you provided.
> >
> > Note I think after the work is done to purge ThreadNodes proactively
> > it might not be that hard of step to move to not needing
> > JVMTI_EVENT_VIRTUAL_THREAD_START/END events enabled, which will help
> > performance a lot more.
> >
> > Chris
> >
> > On 4/1/25 10:14 AM, Egor Ushakov wrote:
> >> Hi everyone!
> >>
> >> Is it expected that with the debugger attached creating virtual
> >> threads is much slower?
> >> We're getting bugs like:
> >> https://youtrack.jetbrains.com/issue/IDEA-365900
> >> And I can reproduce it easily with jdb...
> >> Just attaching the debugger immediately slows down virtual threads
> >> creation significantly.
> >>
> >> >java
> >> -agentlib:jdwp=transport=dt_shmem,server=y,suspend=n,address=8000 app
> >> ...
> >> 6808805 (1.2046688E7 threads per second)
> >> ...
> >> after >jdb -attach 8000
> >> ...
> >> 30215 (95986.055 threads per second)
> >> ...
> >>
> >> Thanks,
> >> Egor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/serviceability-dev/attachments/20250403/85e99948/attachment.htm>
From iklam at openjdk.org Thu Apr 3 21:10:51 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Apr 2025 21:10:51 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v2]
In-Reply-To: <dK9GtrRADdKtBLFcFjALdk3TdDZ0YJnENHmUCbgt_bI=.57118b11-7dc0-4d93-b02a-b110e1e745d1@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
<dK9GtrRADdKtBLFcFjALdk3TdDZ0YJnENHmUCbgt_bI=.57118b11-7dc0-4d93-b02a-b110e1e745d1@github.com>
Message-ID: <gLJvh4fTkZZHj4Malumr6Bc4UZB8Iwov1m28JgCZyxk=.e19d2067-0eab-41f8-b989-a0c468282a7c@github.com>
On Thu, 3 Apr 2025 19:33:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>>
>> more clean up
>
> test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java line 28:
>
>> 26: * @test
>> 27: * @summary "AOT" aliases for traditional CDS command-line options
>> 28: * @requires vm.cds & vm.compMode != "Xcomp"
>
> The test completely ignore external VM flags, so it should have
> `@requires vm.flagless `
> and no Xcomp exclusion is required.
Fixed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2027743880
From iklam at openjdk.org Thu Apr 3 21:43:56 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 3 Apr 2025 21:43:56 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v2]
In-Reply-To: <RjLZX5oc4x77uuGSRtZ2jC5n_0G_Bcia3gVbCFsS6LY=.487eb5ab-a28c-4fcd-bd76-6fa993243122@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
<RjLZX5oc4x77uuGSRtZ2jC5n_0G_Bcia3gVbCFsS6LY=.487eb5ab-a28c-4fcd-bd76-6fa993243122@github.com>
Message-ID: <hIM0L5pWqYODQAnc0TJvXZi7bjBGTlZx_RlT_nMrzUk=.36ee17a3-ef8f-4b83-a8ce-9d7e6013890a@github.com>
On Thu, 3 Apr 2025 15:56:02 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded.
>
> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`:
>
> ```
> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) {
> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true);
> ...
> if (AOTClassLinking && is_dumping_final_static_archive()) {
> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true);
> ```
>
> First, I am not sure these conditions are correct.
>
> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`.
>
> May be also consider it is error if both conditions are true (we don't support updating archive yet).
There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code.
In the handling of such "AOT capability flags", I have been using the following pattern:
In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default.
if (!FLAG_IS_DEFAULT(AOTMode)) {
// Using any form of the new AOTMode switch enables enhanced optimizations.
FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true);
}
if (AOTClassLinking) {
// If AOTClassLinking is specified, enable all AOT optimizations by default.
FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true);
} else {
// AOTInvokeDynamicLinking depends on AOTClassLinking.
FLAG_SET_ERGO(AOTInvokeDynamicLinking, false);
}
However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used.
Because the dependencies are complex, it's difficult to resolve them statically and set a global boolean variable for each capability. Instead, I have been expressing the dependencies programmatically using accessor functions:
bool CDSConfig::is_dumping_aot_linked_classes() {
if (is_dumping_preimage_static_archive()) {
return false;
} else if (is_dumping_dynamic_archive()) {
return is_using_full_module_graph() && AOTClassLinking;
} else if (is_dumping_static_archive()) {
return is_dumping_full_module_graph() && AOTClassLinking;
} else {
return false;
}
}
bool CDSConfig::is_dumping_invokedynamic() {
// Requires is_dumping_aot_linked_classes(). Otherwise the classes of some archived heap
// objects used by the archive indy callsites may be replaced at runtime.
return AOTInvokeDynamicLinking && is_dumping_aot_linked_classes() && is_dumping_heap();
}
I would suggest doing something like this for storing AOT code:
bool CDSConfig::is_dumping_aot_code() {
return StoreAOTCode && is_dumping_final_static_archive() && is_dumping_aot_linked_classes();
}
For loading AOT code, it's simpler. We can do a definite check immediately after the AOT cache has been mapped. This also makes the run-time check efficient (whereas the assembly-time checks can take their time).
if (LoadAOTCode && cache has AOT code && vm options are compatible) {
CDSConfig::_is_using_aot_code = true;
} else {
CDSConfig::_is_using_aot_code = false;
}
inline bool CDSConfig::is_using_aot_code() {
return CDSConfig::_is_using_aot_code;
}
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2776976568
From kvn at openjdk.org Thu Apr 3 22:04:54 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 3 Apr 2025 22:04:54 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v2]
In-Reply-To: <hIM0L5pWqYODQAnc0TJvXZi7bjBGTlZx_RlT_nMrzUk=.36ee17a3-ef8f-4b83-a8ce-9d7e6013890a@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
<RjLZX5oc4x77uuGSRtZ2jC5n_0G_Bcia3gVbCFsS6LY=.487eb5ab-a28c-4fcd-bd76-6fa993243122@github.com>
<hIM0L5pWqYODQAnc0TJvXZi7bjBGTlZx_RlT_nMrzUk=.36ee17a3-ef8f-4b83-a8ce-9d7e6013890a@github.com>
Message-ID: <X8Hu2K8M2ATW-h1bLWrLMXSOrYgRdYGegSPjXlXwXZI=.7a96bcd1-dd94-4006-b79d-14fade32f732@github.com>
On Thu, 3 Apr 2025 21:40:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded.
>>
>> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`:
>>
>> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) {
>> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true);
>> ...
>> if (AOTClassLinking && is_dumping_final_static_archive()) {
>> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true);
>>
>>
>> First, I am not sure these conditions are correct.
>>
>> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`.
>>
>> May be also consider it is error if both conditions are true (we don't support updating archive yet).
>
>> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded.
>>
>> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`:
>>
>> ```
>> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) {
>> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true);
>> ...
>> if (AOTClassLinking && is_dumping_final_static_archive()) {
>> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true);
>> ```
>>
>> First, I am not sure these conditions are correct.
>>
>> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`.
>>
>> May be also consider it is error if both conditions are true (we don't support updating archive yet).
>
> There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code.
>
> In the handling of such "AOT capability flags", I have been using the following pattern:
>
> In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default.
>
>
> if (!FLAG_IS_DEFAULT(AOTMode)) {
> // Using any form of the new AOTMode switch enables enhanced optimizations.
> FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true);
> }
>
> if (AOTClassLinking) {
> // If AOTClassLinking is specified, enable all AOT optimizations by default.
> FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true);
> } else {
> // AOTInvokeDynamicLinking depends on AOTClassLinking.
> FLAG_SET_ERGO(AOTInvokeDynamicLinking, false);
> }
>
>
> However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used.
>
> Because the dependencies are complex, it's difficult to resolve them statically and set a global boolean variable for each capability. Instead, I have been expres...
Thank you @iklam for explanation. I can do final adjustment to `Store|LoadAOTCode` flags values in `StoreAOTCode::initialize()` which is called from `initialize_shared_spaces()`:
MetaspaceShared::initialize_shared_spaces() {
...
static_mapinfo->patch_heap_embedded_pointers();
ArchiveHeapLoader::finish_initialization();
Universe::load_archived_object_instances();
+ AOTCodeCache::initialize();
The question: at this place are all CDS AOT flags are final (flags compatibility and cache presence are verified)?
Note, `Store|LoadAOTCode` flags are diagnostic and disabled by default. I need to set them to `true` somewhere.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2777090009
From sspitsyn at openjdk.org Fri Apr 4 06:23:52 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 4 Apr 2025 06:23:52 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
timed out [v2]
In-Reply-To: <iAYNgKws-37b1b8PHBZhN4tyaXgKgvm9AuA5WNQvPWI=.9c7949f1-9837-4a1e-8055-200718aefdff@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
<zDha5jkc0ajVnhq1bXoOPKQ4M9RXjdDMDfJcq4_ZPtI=.619e6269-1c58-4ab5-9570-9ab397df5922@github.com>
<iAYNgKws-37b1b8PHBZhN4tyaXgKgvm9AuA5WNQvPWI=.9c7949f1-9837-4a1e-8055-200718aefdff@github.com>
Message-ID: <XlHX9roympjELefi8aLirpIsEggB_qx5chzEeB4xgVY=.8d343e49-e2b0-4971-8cf4-964b60c41a32@github.com>
On Thu, 3 Apr 2025 17:58:30 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>>
>> some cleanup
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 1078:
>
>> 1076: JvmtiEnv::ResumeThread(jthread thread) {
>> 1077: // resume thread with handshake
>> 1078: ResumeThreadClosure op(/* single_resume */ true);
>
> Could you please explain how thread is protected from racing with mounting<->unmounting operations with resume_thread operations?
> It might be unlikely happens for suspended threads, but for alive threads the results are not defined.
Thank you for the question. The `JvmtiHanshake::execute()` has a `JvmtiVTMSTransitionDisabler` installed:
JvmtiHandshake::execute(JvmtiUnitedHandshakeClosure* hs_cl, jthread target) {
JavaThread* current = JavaThread::current();
HandleMark hm(current);
JvmtiVTMSTransitionDisabler disabler(target); <= !!!!!!!
. . .
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1759:
>
>> 1757: Handle thread_h(current, thread_oop);
>> 1758: bool is_virtual = java_lang_VirtualThread::is_instance(thread_h());
>> 1759: bool is_thread_carrying = is_thread_carrying_vthread(java_thread, thread_h());
>
> I think that somewhere in this place should be an explanation of suspend<->resume synchronization. As I understand the hadshake can't be executed and clear suspend state while suspend_thread is done for the same thread. How it is guaranteed that suspend_thread flag cann't be updated?
> It is not obvious and also put some restrictions on the suspend_thread implementation to keep this behaviour.
Thank you for reviewing and this suggestion.
Yes, you are right. I'll try to find a good place to add such a comment.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2028158825
PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2028161088
From varadam at openjdk.org Fri Apr 4 06:43:55 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 06:43:55 GMT
Subject: RFR: 8352392: AIX: implement attach API v2 and streaming output
[v4]
In-Reply-To: <jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
References: <EABlUJgtOZv85Bo5DANULH-2CBxBON1IJAkEcEN6dm4=.5cc0fffa-dd91-4e8d-aa95-610cd2955e59@github.com>
<jRiQkH_gXA0VdRQqjJym7pgY8nvhzn-uGegEd2nKrIQ=.9f271e7f-058e-451b-95e6-2cd480ca17bf@github.com>
Message-ID: <tlkiNu1LZZ9gKNZpwXIfsJ6WpppJfeRDZfPFNPZuLzM=.0ce49347-5935-4353-9c03-16341fbc157a@github.com>
On Tue, 1 Apr 2025 10:30:56 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 one additional commit since the last revision:
>
> 8352392: AIX: implement attach API v2 and streaming output
Thanks all,
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24177#issuecomment-2777687525
From varadam at openjdk.org Fri Apr 4 06:43:56 2025
From: varadam at openjdk.org (Varada M)
Date: Fri, 4 Apr 2025 06:43:56 GMT
Subject: Integrated: 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: <MUpnYPyCZqihu0LbyQZpKZEl7lVbsTIwdivzxzFrl24=.986aa77d-2ef5-4a23-9a02-7549bbb03466@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 now been integrated.
Changeset: 41d4a0d7
Author: Varada M <varadam at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/41d4a0d7bdda2a96af1e7f549c05d99d68c040dc
Stats: 283 lines in 3 files changed: 64 ins; 203 del; 16 mod
8352392: AIX: implement attach API v2 and streaming output
Reviewed-by: mdoerr, jkern, amenkov
-------------
PR: https://git.openjdk.org/jdk/pull/24177
From serb at openjdk.org Fri Apr 4 09:29:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 4 Apr 2025 09:29:56 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: <UqAxIGkRD-5PJP1TPZknNjV7x--0vvlRoGsQSDkPxIg=.2b8593d1-c717-4f20-9d4b-ae78d46770ff@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
src/jdk.attach/macosx/native/libattach/VirtualMachineImpl.c line 118:
> 116: * Signature: (I)V
> 117: */
> 118: JNIEXPORT jboolean JNICALL Java_sun_tools_attach_VirtualMachineImpl_checkCatchesAndSendQuitTo
I?m just curious - why does this method return a boolean? It looks like the result is never actually checked, and the control flow is managed through exceptions or errors(on both linux and macos).
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24085#discussion_r2028449674
From iklam at openjdk.org Sun Apr 6 21:30:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Sun, 6 Apr 2025 21:30:49 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v2]
In-Reply-To: <hIM0L5pWqYODQAnc0TJvXZi7bjBGTlZx_RlT_nMrzUk=.36ee17a3-ef8f-4b83-a8ce-9d7e6013890a@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
<RjLZX5oc4x77uuGSRtZ2jC5n_0G_Bcia3gVbCFsS6LY=.487eb5ab-a28c-4fcd-bd76-6fa993243122@github.com>
<hIM0L5pWqYODQAnc0TJvXZi7bjBGTlZx_RlT_nMrzUk=.36ee17a3-ef8f-4b83-a8ce-9d7e6013890a@github.com>
Message-ID: <z0WbHZ9p2rn4NsowS_6s5kxQSML6ui6Z2F7jfTcKNu0=.69400e94-cc1f-439c-ba6d-50c423f362c2@github.com>
On Thu, 3 Apr 2025 21:40:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded.
>>
>> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`:
>>
>> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) {
>> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true);
>> ...
>> if (AOTClassLinking && is_dumping_final_static_archive()) {
>> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true);
>>
>>
>> First, I am not sure these conditions are correct.
>>
>> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`.
>>
>> May be also consider it is error if both conditions are true (we don't support updating archive yet).
>
>> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded.
>>
>> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`:
>>
>> ```
>> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) {
>> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true);
>> ...
>> if (AOTClassLinking && is_dumping_final_static_archive()) {
>> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true);
>> ```
>>
>> First, I am not sure these conditions are correct.
>>
>> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`.
>>
>> May be also consider it is error if both conditions are true (we don't support updating archive yet).
>
> There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code.
>
> In the handling of such "AOT capability flags", I have been using the following pattern:
>
> In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default.
>
>
> if (!FLAG_IS_DEFAULT(AOTMode)) {
> // Using any form of the new AOTMode switch enables enhanced optimizations.
> FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true);
> }
>
> if (AOTClassLinking) {
> // If AOTClassLinking is specified, enable all AOT optimizations by default.
> FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true);
> } else {
> // AOTInvokeDynamicLinking depends on AOTClassLinking.
> FLAG_SET_ERGO(AOTInvokeDynamicLinking, false);
> }
>
>
> However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used.
>
> Because the dependencies are complex, it's difficult to resolve them statically and set a global boolean variable for each capability. Instead, I have been expres...
> Thank you @iklam for explanation. I can do final adjustment to `Store|LoadAOTCode` flags values in `StoreAOTCode::initialize()` which is called from `initialize_shared_spaces()`:
>
> ```
> MetaspaceShared::initialize_shared_spaces() {
> ...
> static_mapinfo->patch_heap_embedded_pointers();
> ArchiveHeapLoader::finish_initialization();
> Universe::load_archived_object_instances();
> + AOTCodeCache::initialize();
> ```
>
> The question: at this place are all CDS AOT flags are final (flags compatibility and cache presence are verified)?
>
> Note, `Store|LoadAOTCode` flags are diagnostic and disabled by default. I need to set them to `true` somewhere.
Yes, at this point all configuration related to AOT should be final. You can set the final values for the `Store|LoadAOTCode` flags here.
`StoreAOTCode` should be true only if `CDSConfig::is_dumping_final_static_archive()` is true. `LoadAOTCode` should be true only if `CDSConfig::is_loading_archive()` is true and the archive contains AOT code.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2781681413
From dholmes at openjdk.org Mon Apr 7 07:39:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 7 Apr 2025 07:39:54 GMT
Subject: RFR: 8353231: Test
com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails
intermittently
In-Reply-To: <PIhaXE0X5mOumCzQefIhCwiC-BZ-C3lAZPOknY0Vaac=.077220d2-7b53-47bb-aad1-0a42d0a664ba@github.com>
References: <PIhaXE0X5mOumCzQefIhCwiC-BZ-C3lAZPOknY0Vaac=.077220d2-7b53-47bb-aad1-0a42d0a664ba@github.com>
Message-ID: <igVb1Z-pPZqIy-PDGAjOcfzGqF5Z5H18X6ZjE_ET0B0=.a32a7260-e715-4a15-b742-48265abfb26b@github.com>
On Tue, 1 Apr 2025 10:27:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> Test com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails intermittently.
> On failure, 10 attempts with sleep(200) each time, only read -1 from mbean.getProcessCpuLoad().
> The method is documented to return -1 when info is not available, but want to avoid the test accepting a -1 and masking real problems.
>
> Test failures are happening when multiple CPU load reding tests ran on the same host, at the same second.
> Add a TEST.properties file containing: exclusiveAccess.dirs=.
Okay lets give this a try.
Thanks
-------------
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24352#pullrequestreview-2745797954
From kevinw at openjdk.org Mon Apr 7 09:28:38 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Apr 2025 09:28:38 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p
Message-ID: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
It has always done a manual "root plus pid plus extension" on the default filename only, and
should move to using Argument::copy_expand_pid() like we do with other such filenames.
We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
-------------
Commit messages:
- 8353727: HeapDumpPath doesn't expand %p
Changes: https://git.openjdk.org/jdk/pull/24482/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353727
Stats: 73 lines in 2 files changed: 26 ins; 23 del; 24 mod
Patch: https://git.openjdk.org/jdk/pull/24482.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482
PR: https://git.openjdk.org/jdk/pull/24482
From jkern at openjdk.org Mon Apr 7 09:58:50 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 7 Apr 2025 09:58:50 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v3]
In-Reply-To: <pENA7rNLFax4lrCdieDSNxFQ58RsHjmCkj2UWFb0tTo=.87bb0fc6-1cd4-49ad-9ce0-170273fbd8e8@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<pENA7rNLFax4lrCdieDSNxFQ58RsHjmCkj2UWFb0tTo=.87bb0fc6-1cd4-49ad-9ce0-170273fbd8e8@github.com>
Message-ID: <ZpgtNCV0rnJuTTf-1WGLFjqtfUG4jbCfiRE88jkos_8=.2c6f996c-1639-48b1-af3d-eaff885e983d@github.com>
On Thu, 3 Apr 2025 15:27:15 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 i...
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>
> exclude file mapping tests on AIX.
I ran the tests over the weekend again and now they passed.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2782761982
From kevinw at openjdk.org Mon Apr 7 11:36:55 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Apr 2025 11:36:55 GMT
Subject: RFR: 8353231: Test
com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails
intermittently
In-Reply-To: <PIhaXE0X5mOumCzQefIhCwiC-BZ-C3lAZPOknY0Vaac=.077220d2-7b53-47bb-aad1-0a42d0a664ba@github.com>
References: <PIhaXE0X5mOumCzQefIhCwiC-BZ-C3lAZPOknY0Vaac=.077220d2-7b53-47bb-aad1-0a42d0a664ba@github.com>
Message-ID: <yaqEkj2Fk1u956WX3ypqBrIKv8NwV_65JsvhS11EaN4=.65028f30-0db3-484c-a409-e3408e3ea07c@github.com>
On Tue, 1 Apr 2025 10:27:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> Test com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails intermittently.
> On failure, 10 attempts with sleep(200) each time, only read -1 from mbean.getProcessCpuLoad().
> The method is documented to return -1 when info is not available, but want to avoid the test accepting a -1 and masking real problems.
>
> Test failures are happening when multiple CPU load reding tests ran on the same host, at the same second.
> Add a TEST.properties file containing: exclusiveAccess.dirs=.
Thanks David!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24352#issuecomment-2783014959
From kevinw at openjdk.org Mon Apr 7 11:36:55 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Apr 2025 11:36:55 GMT
Subject: Integrated: 8353231: Test
com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails
intermittently
In-Reply-To: <PIhaXE0X5mOumCzQefIhCwiC-BZ-C3lAZPOknY0Vaac=.077220d2-7b53-47bb-aad1-0a42d0a664ba@github.com>
References: <PIhaXE0X5mOumCzQefIhCwiC-BZ-C3lAZPOknY0Vaac=.077220d2-7b53-47bb-aad1-0a42d0a664ba@github.com>
Message-ID: <V_ARdTAlMs3I4dlAmat9_bLYdUlPh_coT8GFch3YSnw=.a286ae4a-3982-4bde-81dc-59e0f90e2bbb@github.com>
On Tue, 1 Apr 2025 10:27:39 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> Test com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails intermittently.
> On failure, 10 attempts with sleep(200) each time, only read -1 from mbean.getProcessCpuLoad().
> The method is documented to return -1 when info is not available, but want to avoid the test accepting a -1 and masking real problems.
>
> Test failures are happening when multiple CPU load reding tests ran on the same host, at the same second.
> Add a TEST.properties file containing: exclusiveAccess.dirs=.
This pull request has now been integrated.
Changeset: e8c9e5c6
Author: Kevin Walls <kevinw at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/e8c9e5c6cd3c844765c27c068022a018914fdf4e
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
8353231: Test com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad still fails intermittently
Reviewed-by: dholmes
-------------
PR: https://git.openjdk.org/jdk/pull/24352
From zgu at openjdk.org Mon Apr 7 12:35:53 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 7 Apr 2025 12:35:53 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p
In-Reply-To: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
Message-ID: <GbaMVkl_Y9_fdm3zA4LeG2Kgy4q4oW7Jsj2YqHlGGEs=.f899c2b5-8f10-4cf8-8c38-452e8e0d08bf@github.com>
On Mon, 7 Apr 2025 09:05:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
> It has always done a manual "root plus pid plus extension" on the default filename only, and
> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>
>
> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
@kevinjwalls I have [JDK-8349083](https://bugs.openjdk.org/browse/JDK-8349083) to address similar issues.
AFAICT, there are 3 separate code to handle filename expansion and logging has the most complete support, It will be nice to unify them.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2783181347
From kevinw at openjdk.org Mon Apr 7 15:01:34 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 7 Apr 2025 15:01:34 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p
In-Reply-To: <GbaMVkl_Y9_fdm3zA4LeG2Kgy4q4oW7Jsj2YqHlGGEs=.f899c2b5-8f10-4cf8-8c38-452e8e0d08bf@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<GbaMVkl_Y9_fdm3zA4LeG2Kgy4q4oW7Jsj2YqHlGGEs=.f899c2b5-8f10-4cf8-8c38-452e8e0d08bf@github.com>
Message-ID: <KwUJLEuid6opMkjVArC1gWPr3MzaizGBybj4JD3OfeM=.4804451d-99a5-48f1-a25c-667bdc6ad96a@github.com>
On Mon, 7 Apr 2025 12:32:52 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> @kevinjwalls I have [JDK-8349083](https://bugs.openjdk.org/browse/JDK-8349083) to address similar issues.
>
> AFAICT, there are 3 separate code to handle filename expansion and logging has the most complete support, It will be nice to unify them.
Hi, thanks for the pointer.
Yes, we have some duplication in this area... This change is quite small, and removes one duplicate, the manual "base+pid+extension" creation of the filename in HeapDumper.
I am looking at the other PR, maybe we can make them share more in future...
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2783639159
From heidinga at openjdk.org Mon Apr 7 17:01:56 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 7 Apr 2025 17:01:56 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v3]
In-Reply-To: <OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
Message-ID: <1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com>
On Thu, 3 Apr 2025 20:31:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>>
>> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>>
>>
>> const char* CDSConfig::input_static_archive_path();
>> const char* CDSConfig::input_dynamic_archive_path();
>> const char* CDSConfig::output_archive_path();
>>
>>
>> This PR also cleans up the code by:
>> - renaming a few function to reflect what they actually do
>> - moving more "config" management code into cdsConfig.cpp
>>
>> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>>
>> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>
> @lmesnik comments
src/hotspot/share/cds/cdsConfig.cpp line 598:
> 596: // - SharedArchiveFile is not specified and the VM doesn't have a compatible default archive
> 597:
> 598: #define __THEMSG " is unsupported when base CDS archive is not loaded. Run with -Xlog:cds for more info."
Do we want to start transitioning existing `-Xlog:cds` options to be `:aot` options? I think making the switch would match out long term direction
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2031644463
From amenkov at openjdk.org Mon Apr 7 18:06:49 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 7 Apr 2025 18:06:49 GMT
Subject: RFR: 8353485: Jcms should allow to specify streaming_output mode
Message-ID: <R9D0dMqa9dWWfp0hrz2DV5J_SsPhEb18gPOxGyo_cws=.973c17a3-ac58-427a-af9f-746b83dc5e10@github.com>
The fix adds `--streaming_output` jcmd option to manage attach command streaming output.
Testing: tier1..tier4,hs-tier5-svc
-------------
Commit messages:
- jcmd_streaming
Changes: https://git.openjdk.org/jdk/pull/24494/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24494&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353485
Stats: 172 lines in 9 files changed: 144 ins; 7 del; 21 mod
Patch: https://git.openjdk.org/jdk/pull/24494.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24494/head:pull/24494
PR: https://git.openjdk.org/jdk/pull/24494
From cjplummer at openjdk.org Tue Apr 8 01:41:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 8 Apr 2025 01:41:39 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p
In-Reply-To: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
Message-ID: <Xsv8yviWk32RrtscQ0SyIMiqqKCKZJsiOfrts-Dc-MQ=.4c762966-e202-4e93-9e8d-1b3438d3ec30@github.com>
On Mon, 7 Apr 2025 09:05:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
> It has always done a manual "root plus pid plus extension" on the default filename only, and
> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>
>
> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
src/hotspot/share/services/heapDumper.cpp line 2772:
> 2770:
> 2771: // Set base path (name or directory, default or custom, without seq no), doing %p substitution.
> 2772: const char *path_src = (HeapDumpPath && HeapDumpPath[0] != '\0') ? HeapDumpPath : dump_file_name;
Should be `HeapDumpPath != nullptr`.
src/hotspot/share/services/heapDumper.cpp line 2792:
> 2790: // Path is a directory. Append the default name, with %p substitution. Use my_path temporarily.
> 2791: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN)) {
> 2792: warning("Cannot create heap dump file. HeapDumpPath is too long.");
What is going to be the end result of this? A truncated file name?
test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 101:
> 99: File dump = new File(heapdumpFilename);
> 100: Asserts.assertTrue(dump.exists() && dump.isFile(), "Could not find dump file " + dump.getAbsolutePath());
> 101:
I think you can remove this empty line, especially since you don't have one in the similar code below.
test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 113:
> 111: TestHeapDumpOnOutOfMemoryError.class.getName(), type);
> 112:
> 113: Process proc = pb.start();
No need differ from the above code here. You can just use OutputAnalyzer.pid() to get the pid in the code below.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032238479
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032243030
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032233983
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032234654
From jiangli at openjdk.org Tue Apr 8 02:31:57 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 8 Apr 2025 02:31:57 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK
Message-ID: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
Please review this PR that changes `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` shared library if running on static JDK, instead just returns "libinstrument.<ext>" directly. Both test case #1 and #2 in `LoadAgentDcmdTest.run()` run ok on static JDK with the change:
Commands:
Test case #1: `JVMTI.agent_load libinstrument.so agent.jar`
Test case #2: `JVMTI.agent_load libinstrument.so "agent.jar=foo=bar"`
Additional notes/considerations:
1. I notice [JDKToolFinder.getJDKTool()](https://github.com/openjdk/jdk/blob/80ff7b9c9406c7845ecb3bc40910e92ccdd23ff2/test/lib/jdk/test/lib/JDKToolFinder.java#L41) is used by the test to find the `jcmd` tool. `JDKToolFinder.getJDKTool()` looks for the requested tool in both `test.jdk` and `compile.jdk`. When running the jtreg test on static JDK, it's able to locate the `jcmd` from `compile.jdk` even though the static JDK binary (`test.jdk`) does not provide the tool. For tools used by jtreg tests at runtime, how about change to always do that?
2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
JVMTI.agent_load [arguments]
Loads JVMTI native agent.
Impact: Low
arguments:
library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
agent option: (Optional) Option string to pass the agent. (STRING, no default value)
The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
-------------
Commit messages:
- Replace "so" with Platform.sharedLibraryExt().
- Change LoadAgentDcmdTest.getLibInstrumentPath() to return "libinstrument.so" directly without locating the shared library if running on static JDK.
Changes: https://git.openjdk.org/jdk/pull/24497/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24497&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353938
Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/24497.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24497/head:pull/24497
PR: https://git.openjdk.org/jdk/pull/24497
From sspitsyn at openjdk.org Tue Apr 8 03:16:30 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 8 Apr 2025 03:16:30 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
timed out [v3]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <QB2mJoKKGaVe3kfxtSNmhKLjQ4WmyOKLh977pMr0nr8=.8c71504e-df5a-425c-9ce1-9c230184e674@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
- Merge
- some cleanup
- 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest timed out
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24269/files
- new: https://git.openjdk.org/jdk/pull/24269/files/18944347..4a92986a
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=01-02
Stats: 68856 lines in 1040 files changed: 24634 ins; 41255 del; 2967 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 kevinw at openjdk.org Tue Apr 8 09:02:13 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Apr 2025 09:02:13 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p
In-Reply-To: <Xsv8yviWk32RrtscQ0SyIMiqqKCKZJsiOfrts-Dc-MQ=.4c762966-e202-4e93-9e8d-1b3438d3ec30@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<Xsv8yviWk32RrtscQ0SyIMiqqKCKZJsiOfrts-Dc-MQ=.4c762966-e202-4e93-9e8d-1b3438d3ec30@github.com>
Message-ID: <ejdgYbwC-16A1NwTDxVgB4eh5aKHaXzIeFDZEwWN87k=.266b4153-6096-4933-84df-6390faabf92b@github.com>
On Tue, 8 Apr 2025 01:37:21 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
>> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
>> It has always done a manual "root plus pid plus extension" on the default filename only, and
>> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>>
>>
>> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
>
> src/hotspot/share/services/heapDumper.cpp line 2792:
>
>> 2790: // Path is a directory. Append the default name, with %p substitution. Use my_path temporarily.
>> 2791: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN)) {
>> 2792: warning("Cannot create heap dump file. HeapDumpPath is too long.");
>
> What is going to be the end result of this? A truncated file name?
Yes the other warnings return - thanks.
They all return without incrementing dump_seq, so will hit the same failure each time.
Setting a HeapDumpPath near to 4k in length is not an efficient thing to do!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2032733570
From rehn at openjdk.org Tue Apr 8 09:44:23 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 8 Apr 2025 09:44:23 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
<5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
Message-ID: <Z3YLQS6BI586H_bxkEs2JM3e1wTFlGLZA26klriEKP8=.d13460f0-80f5-42c7-8ea8-51370932e126@github.com>
On Mon, 31 Mar 2025 10:45:54 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 explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>>
>> 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
Any takers?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2785851072
From kevinw at openjdk.org Tue Apr 8 11:43:20 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Apr 2025 11:43:20 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
Message-ID: <hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
> It has always done a manual "root plus pid plus extension" on the default filename only, and
> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>
>
> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
- length checking update
- Chris feedback
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24482/files
- new: https://git.openjdk.org/jdk/pull/24482/files/ab82116e..c32e4ca4
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=00-01
Stats: 23 lines in 2 files changed: 1 ins; 15 del; 7 mod
Patch: https://git.openjdk.org/jdk/pull/24482.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482
PR: https://git.openjdk.org/jdk/pull/24482
From kevinw at openjdk.org Tue Apr 8 11:47:20 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Apr 2025 11:47:20 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
Message-ID: <lAfbQQXsT-uvH8Wjx_PyVt5s1HS1T0lmgwi20aycSvo=.ad704035-3f66-4990-9c57-2a75b1e8ba5c@github.com>
On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
>> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
>> It has always done a manual "root plus pid plus extension" on the default filename only, and
>> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>>
>>
>> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>
> - length checking update
> - Chris feedback
Updated.
Additionally, the total_length check at line 2760 is wrong now. But it is also redundant, we use copy_expand_pid to do our length checks on expansion. Use max_digit_chars to reduce buffer length in those copy_expand_pid calls, to leave room for possible later sequence numbers (this is very conservative).
On longer path lengths, worth noting that using MAXPATHLEN (4k) is higher than outputStream::print_cr allows.
This means we can get through all of HeapDumper::dump_heap(bool oome) and call HeapDumper::dump() which uses:
2606 out->print_cr("Dumping heap to %s ...", path);
..and will show a VM warning like "outputStream::do_vsnprintf output truncated"
Again, very very long HeapDumpPaths are not efficient. 8-)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2786165819
From stuefe at openjdk.org Tue Apr 8 11:54:21 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Apr 2025 11:54:21 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <lAfbQQXsT-uvH8Wjx_PyVt5s1HS1T0lmgwi20aycSvo=.ad704035-3f66-4990-9c57-2a75b1e8ba5c@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
<lAfbQQXsT-uvH8Wjx_PyVt5s1HS1T0lmgwi20aycSvo=.ad704035-3f66-4990-9c57-2a75b1e8ba5c@github.com>
Message-ID: <HL5_kKdjLjn6XIzgPX-ZUwQpECH6DoCMIUbhrHWgaT4=.2c4a1afc-4b94-4d24-8606-d9ea1ec1c91f@github.com>
On Tue, 8 Apr 2025 11:44:52 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> Updated. Additionally, the total_length check at line 2760 is wrong now. But it is also redundant, we use copy_expand_pid to do our length checks on expansion. Use max_digit_chars to reduce buffer length in those copy_expand_pid calls, to leave room for possible later sequence numbers (this is very conservative).
>
> On longer path lengths, worth noting that using MAXPATHLEN (4k) is higher than outputStream::print_cr allows. This means we can get through all of HeapDumper::dump_heap(bool oome) and call HeapDumper::dump() which uses: 2606 out->print_cr("Dumping heap to %s ...", path); ..and will show a VM warning like "outputStream::do_vsnprintf output truncated"
>
> Again, very very long HeapDumpPaths are not efficient. 8-)
I keep thinking that such a coding can benefit from using stringStream; it makes most of the associated buffer counting etc obsolete, supports dynamic buffers, or optionally can be laid over a fixed-sized buffer and then handles truncation. It does not yet provide a way to report truncation, but that can be added really easily.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2786180952
From kevinw at openjdk.org Tue Apr 8 12:12:11 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Apr 2025 12:12:11 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <HL5_kKdjLjn6XIzgPX-ZUwQpECH6DoCMIUbhrHWgaT4=.2c4a1afc-4b94-4d24-8606-d9ea1ec1c91f@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
<lAfbQQXsT-uvH8Wjx_PyVt5s1HS1T0lmgwi20aycSvo=.ad704035-3f66-4990-9c57-2a75b1e8ba5c@github.com>
<HL5_kKdjLjn6XIzgPX-ZUwQpECH6DoCMIUbhrHWgaT4=.2c4a1afc-4b94-4d24-8606-d9ea1ec1c91f@github.com>
Message-ID: <jQ7IXOQzivdRE3wIOFmv2r3bn0Gzj8F9STfaQQWHTvo=.d460ae22-0a18-48fa-b5ce-b199cf2cd5e3@github.com>
On Tue, 8 Apr 2025 11:51:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> I keep thinking that such a coding can benefit from using stringStream; it makes most of the associated buffer counting etc obsolete, supports dynamic buffers, or optionally can be laid over a fixed-sized buffer and then handles truncation. It does not yet provide a way to report truncation, but that can be added really easily.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2786226321
From stuefe at openjdk.org Tue Apr 8 13:16:20 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Apr 2025 13:16:20 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
Message-ID: <ImKE8_3pQ7aLqk1VzTgynjaS5uGBFkaZBvVEwdDNVSk=.1a8ed884-f75e-422a-93a1-98264cd7fc45@github.com>
On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
>> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
>> It has always done a manual "root plus pid plus extension" on the default filename only, and
>> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>>
>>
>> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>
> - length checking update
> - Chris feedback
src/hotspot/share/services/heapDumper.cpp line 2779:
> 2777: }
> 2778: // Then add the default name, with %p substitution. Use my_path temporarily.
> 2779: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN - max_digit_chars)) {
IIUC there is a pre-existing bug, and if I am right one you should fix: this calculation assumes that there is only a single %p. There may be multiple. Many. E.g. as a malicious attempt to cause a buffer overflow.
This is what I meant with stringStream. stringStream offers protection against stuff like that without the manual buffer counting headaches. I would give Arguments a method like this:
print_expand_pid(outputStream* sink, const char* input);
and in there print to sink, with print or putc. This would never truncate. Then use it like this:
outputStream st(caller buffer, caller buffer size)
if (have HeapDumpPath) {
Arguments::print_expand_pid(st, HeapDumpPath);
if (st->was_truncated()) return with warning
// now st->base() ist der expanded heap path. Test if its a directory etc
}
// append file name
Arguments::print_expand_pid(st, dump_file_name);
if (st->was_truncated()) return with warning
Just a rough sketch. And fine for followup PRs, though I think it may make your life easier if you do it now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2033167264
From kevinw at openjdk.org Tue Apr 8 13:50:19 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 8 Apr 2025 13:50:19 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <ImKE8_3pQ7aLqk1VzTgynjaS5uGBFkaZBvVEwdDNVSk=.1a8ed884-f75e-422a-93a1-98264cd7fc45@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
<ImKE8_3pQ7aLqk1VzTgynjaS5uGBFkaZBvVEwdDNVSk=.1a8ed884-f75e-422a-93a1-98264cd7fc45@github.com>
Message-ID: <tzNRe7mVrqQq59KjvPJEY-g9nFGmbVXNPrHmxPo1Ij8=.3d56a7a2-2645-41c2-bac5-9ce13ed11314@github.com>
On Tue, 8 Apr 2025 13:13:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - length checking update
>> - Chris feedback
>
> src/hotspot/share/services/heapDumper.cpp line 2779:
>
>> 2777: }
>> 2778: // Then add the default name, with %p substitution. Use my_path temporarily.
>> 2779: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN - max_digit_chars)) {
>
> IIUC there is a pre-existing bug, and if I am right one you should fix: this calculation assumes that there is only a single %p. There may be multiple. Many. E.g. as a malicious attempt to cause a buffer overflow.
>
> This is what I meant with stringStream. stringStream offers protection against stuff like that without the manual buffer counting headaches. I would give Arguments a method like this:
>
> print_expand_pid(outputStream* sink, const char* input);
>
>
> and in there print to sink, with print or putc. This would never truncate. Then use it like this:
>
>
> outputStream st(caller buffer, caller buffer size)
> if (have HeapDumpPath) {
> Arguments::print_expand_pid(st, HeapDumpPath);
> if (st->was_truncated()) return with warning
> // now st->base() ist der expanded heap path. Test if its a directory etc
> }
> // append file name
> Arguments::print_expand_pid(st, dump_file_name);
> if (st->was_truncated()) return with warning
>
>
> Just a rough sketch. And fine for followup PRs, though I think it may make your life easier if you do it now.
Thankfully copy_expand_pid does handle multiple %p replacements. It seems good to use that to check the buffer length, partly for that reason, as just knowing a max number of digits wasn't so flexible if many %p were present.
Thanks for the other ideas!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2033234374
From stefank at openjdk.org Tue Apr 8 14:22:27 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 8 Apr 2025 14:22:27 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v3]
In-Reply-To: <pENA7rNLFax4lrCdieDSNxFQ58RsHjmCkj2UWFb0tTo=.87bb0fc6-1cd4-49ad-9ce0-170273fbd8e8@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<pENA7rNLFax4lrCdieDSNxFQ58RsHjmCkj2UWFb0tTo=.87bb0fc6-1cd4-49ad-9ce0-170273fbd8e8@github.com>
Message-ID: <eARbfibOFKAIkTkZjRt4n49yHoVteBYpLlKWGf8-QyU=.62f0cae0-26ee-45b9-ac92-7c8b94462877@github.com>
On Thu, 3 Apr 2025 15:27:15 GMT, Robert Toyonaga <duke at openjdk.org> wrote:
>> ### Update:
>> After some discussion it was decided it's not necessary to expand the lock scope for reserve/commit. Instead, we are opting to add comments explaining the reasons for locking and the conditions to avoid which could lead to races. Some of the new tests can be kept because they are general enough to be useful outside of this context.
>>
>> ### 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:...
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>
> exclude file mapping tests on AIX.
I think this looks good to me, but please seek feedback from others as well.
I've added a couple of suggestions. None of them are required, but I think they would be nice to do.
src/hotspot/share/runtime/os.cpp line 2206:
> 2204: // when it is actually committed. The opposite scenario is not guarded against. pd_commit_memory and
> 2205: // record_virtual_memory_commit do not happen atomically. We assume that there is some external synchronization
> 2206: // that prevents a region from being uncommitted before it is finished being committed.
It's not a requirement, but you get kudos from me if you keep comments lines below 80 lines. I typically don't like code to be 80 lines, but comments tend to be nicer if they are.
test/hotspot/gtest/runtime/test_os.cpp line 1123:
> 1121:
> 1122: char* base = os::reserve_memory(size, false, mtTest);
> 1123: ASSERT_NE(base, (char*) nullptr);
Suggestion:
ASSERT_NOT_NULL(base);
And the same in other places.
test/hotspot/gtest/runtime/test_os.cpp line 1133:
> 1131: }
> 1132:
> 1133: #if !defined(_AIX)
Suggestion:
#if !defined(_AIX)
I suggest a blank line here because this ifdef spans multiple tests and not only the nearest test. Having a blank line makes it clearer that this is a large ifdef that is not only related to the test case that it is bunched up against.
test/hotspot/gtest/runtime/test_os.cpp line 1145:
> 1143: EXPECT_TRUE(result != nullptr);
> 1144:
> 1145: EXPECT_TRUE(strcmp(letters, result)==0);
Suggestion:
EXPECT_TRUE(strcmp(letters, result) == 0);
but probably even better:
Suggestion:
EXPECT_EQ(strcmp(letters, result), 0);
test/hotspot/gtest/runtime/test_os.cpp line 1184:
> 1182: ::close(fd);
> 1183: }
> 1184: #endif
Suggestion:
#endif // !defined(_AIX)
I suggest a blank line and a matching comment. I know some HotSpots devs tend to appreciate those comments.
-------------
Marked as reviewed by stefank (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24084#pullrequestreview-2750137709
PR Review Comment: https://git.openjdk.org/jdk/pull/24084#discussion_r2033287481
PR Review Comment: https://git.openjdk.org/jdk/pull/24084#discussion_r2033292443
PR Review Comment: https://git.openjdk.org/jdk/pull/24084#discussion_r2033303666
PR Review Comment: https://git.openjdk.org/jdk/pull/24084#discussion_r2033294266
PR Review Comment: https://git.openjdk.org/jdk/pull/24084#discussion_r2033307030
From stefank at openjdk.org Tue Apr 8 14:22:27 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 8 Apr 2025 14:22:27 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v3]
In-Reply-To: <eARbfibOFKAIkTkZjRt4n49yHoVteBYpLlKWGf8-QyU=.62f0cae0-26ee-45b9-ac92-7c8b94462877@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<pENA7rNLFax4lrCdieDSNxFQ58RsHjmCkj2UWFb0tTo=.87bb0fc6-1cd4-49ad-9ce0-170273fbd8e8@github.com>
<eARbfibOFKAIkTkZjRt4n49yHoVteBYpLlKWGf8-QyU=.62f0cae0-26ee-45b9-ac92-7c8b94462877@github.com>
Message-ID: <LSpMj_1vtgATeigM8TOK6GBqzHRvJ3VIW3BdXPjWYnU=.d266cf78-a594-47d9-be70-84f1fc3115e1@github.com>
On Tue, 8 Apr 2025 14:11:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>>
>> exclude file mapping tests on AIX.
>
> test/hotspot/gtest/runtime/test_os.cpp line 1145:
>
>> 1143: EXPECT_TRUE(result != nullptr);
>> 1144:
>> 1145: EXPECT_TRUE(strcmp(letters, result)==0);
>
> Suggestion:
>
> EXPECT_TRUE(strcmp(letters, result) == 0);
>
> but probably even better:
> Suggestion:
>
> EXPECT_EQ(strcmp(letters, result), 0);
There are more places like this.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24084#discussion_r2033296961
From alanb at openjdk.org Tue Apr 8 14:29:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 8 Apr 2025 14:29:50 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
delayed task handling
Message-ID: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
`jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.
-------------
Commit messages:
- Merge branch 'master' into JDK-8351927
- Merge branch 'master' into JDK-8351927
- Merge branch 'master' into JDK-8351927
- Merge
- Merge branch 'pull/23702' into JDK-8351927
- Typo
- Address review comments
- Merge branch 'openjdk:master' into JDK-8319447
- Address review comments
- Update
- ... and 51 more: https://git.openjdk.org/jdk/compare/867a0301...30eba776
Changes: https://git.openjdk.org/jdk/pull/24030/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24030&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8351927
Stats: 405 lines in 8 files changed: 332 ins; 41 del; 32 mod
Patch: https://git.openjdk.org/jdk/pull/24030.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24030/head:pull/24030
PR: https://git.openjdk.org/jdk/pull/24030
From mbaesken at openjdk.org Tue Apr 8 14:46:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 8 Apr 2025 14:46:30 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <FNg6AZoti-zzOOqQpEpykZ6leYIL49v2efunCb2T1aw=.0d5e0f4d-03ea-453f-bc8e-9c4aaddfc846@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
<FNg6AZoti-zzOOqQpEpykZ6leYIL49v2efunCb2T1aw=.0d5e0f4d-03ea-453f-bc8e-9c4aaddfc846@github.com>
Message-ID: <-ut2L3mbuwzJxlZJGiGyhMl7_HCpd1QX-kuFOX8m1Lc=.38fc5800-855a-49cd-9f3e-3ccadd19885b@github.com>
On Tue, 1 Apr 2025 11:59:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
> It would be interesting to also see how compilation times varies with optimization level. At least some kind of hint if HIGHEST is like 2x slower than LOW, or if SIZE is slower than LOW at all, etc. The relative speed difference is interesting, but so is it in absolute terms. If a library takes 0.5 seconds on LOW but 1.1 seconds on HIGH on a particular system, it is unlikely to matter much to overall build time anywhere. But if it goes from 15s to 30s on a fast machine, it might be a problem if such performance regressions stack up, especially on slower machines (which includes the ones running GHA).
This is what I got from my Linux x86_64 system using gcc 13.2.0 devkit (opt build). Note that the build operates on a relatively slow filer, this will slow the build time somewhat but that is true for all opt-levels.
rm -rf ./support/modules_libs/jdk.jdwp.agent/libjdwp.so ./jdk/lib/libjdwp.so ./support/native/jdk.jdwp.agent/libjdwp
time make jdk.jdwp.agent-libs-only JOBS=1
gave me these times
**default (LOW)**
real 0m15.661s
user 0m8.763s
sys 0m2.012s
**HIGHEST**
real 0m15.201s
user 0m9.005s
sys 0m2.003s
**SIZE**
real 0m14.263s
user 0m7.905s
sys 0m1.891s
So it looks like SIZE is a little faster than the other, and LOW and HIGHEST are rather similar.
LOW is `-O2` on Linuxx86_64 and HIGHEST is `-O3` , those are maybe rather similar (LOW is a bit misleading because `-O2` is not really that 'low' the gcc docu says about it : 'Optimize even more. GCC performs nearly all supported optimizations that do not involve a space-speed tradeoff.').
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2786694168
From stuefe at openjdk.org Tue Apr 8 15:28:25 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 8 Apr 2025 15:28:25 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <tzNRe7mVrqQq59KjvPJEY-g9nFGmbVXNPrHmxPo1Ij8=.3d56a7a2-2645-41c2-bac5-9ce13ed11314@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
<ImKE8_3pQ7aLqk1VzTgynjaS5uGBFkaZBvVEwdDNVSk=.1a8ed884-f75e-422a-93a1-98264cd7fc45@github.com>
<tzNRe7mVrqQq59KjvPJEY-g9nFGmbVXNPrHmxPo1Ij8=.3d56a7a2-2645-41c2-bac5-9ce13ed11314@github.com>
Message-ID: <xG0ne-R7LuavJg6F8R4R2rpQtehvWwhOLwbICk4rkTw=.c6cbf9e0-6c5f-4721-abf1-4f26dba0a20d@github.com>
On Tue, 8 Apr 2025 13:47:10 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> src/hotspot/share/services/heapDumper.cpp line 2779:
>>
>>> 2777: }
>>> 2778: // Then add the default name, with %p substitution. Use my_path temporarily.
>>> 2779: if (!Arguments::copy_expand_pid(dump_file_name, strlen(dump_file_name), my_path, JVM_MAXPATHLEN - max_digit_chars)) {
>>
>> IIUC there is a pre-existing bug, and if I am right one you should fix: this calculation assumes that there is only a single %p. There may be multiple. Many. E.g. as a malicious attempt to cause a buffer overflow.
>>
>> This is what I meant with stringStream. stringStream offers protection against stuff like that without the manual buffer counting headaches. I would give Arguments a method like this:
>>
>> print_expand_pid(outputStream* sink, const char* input);
>>
>>
>> and in there print to sink, with print or putc. This would never truncate. Then use it like this:
>>
>>
>> outputStream st(caller buffer, caller buffer size)
>> if (have HeapDumpPath) {
>> Arguments::print_expand_pid(st, HeapDumpPath);
>> if (st->was_truncated()) return with warning
>> // now st->base() ist der expanded heap path. Test if its a directory etc
>> }
>> // append file name
>> Arguments::print_expand_pid(st, dump_file_name);
>> if (st->was_truncated()) return with warning
>>
>>
>> Just a rough sketch. And fine for followup PRs, though I think it may make your life easier if you do it now.
>
> Thankfully copy_expand_pid does handle multiple %p replacements. It seems good to use that to check the buffer length, partly for that reason, as just knowing a max number of digits wasn't so flexible if many %p were present.
>
> Thanks for the other ideas!
Ah okay, it checks for overflow. Okay, please disregard half of what I have written :)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2033452540
From kvn at openjdk.org Tue Apr 8 16:00:21 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 8 Apr 2025 16:00:21 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v3]
In-Reply-To: <1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
<1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com>
Message-ID: <PkIZM2m0oA6iu8tExWP69j4PceSjvUAXGUM0ciKIxTY=.29148411-d706-4882-8ef6-3ffa8806ec13@github.com>
On Mon, 7 Apr 2025 16:54:37 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:
>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>>
>> @lmesnik comments
>
> src/hotspot/share/cds/cdsConfig.cpp line 598:
>
>> 596: // - SharedArchiveFile is not specified and the VM doesn't have a compatible default archive
>> 597:
>> 598: #define __THEMSG " is unsupported when base CDS archive is not loaded. Run with -Xlog:cds for more info."
>
> Do we want to start transitioning existing `-Xlog:cds` options to be `:aot` options? I think making the switch would match out long term direction
Yes, but I think we should do it only if `AOTClassLinking` is enabled. For legacy CDS we should continue use `-Xlog:cds`.
I am using `-Xlog:aot+codecache` in AOT code caching.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2033524434
From iklam at openjdk.org Tue Apr 8 16:29:21 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 8 Apr 2025 16:29:21 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v3]
In-Reply-To: <PkIZM2m0oA6iu8tExWP69j4PceSjvUAXGUM0ciKIxTY=.29148411-d706-4882-8ef6-3ffa8806ec13@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
<1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com>
<PkIZM2m0oA6iu8tExWP69j4PceSjvUAXGUM0ciKIxTY=.29148411-d706-4882-8ef6-3ffa8806ec13@github.com>
Message-ID: <jtv6CFfiBgokjjs43XMzZJgQFycEBUHLmaEKoBGtdGs=.fa34be7c-5913-490e-9513-6b1945137fef@github.com>
On Tue, 8 Apr 2025 15:57:46 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>> src/hotspot/share/cds/cdsConfig.cpp line 598:
>>
>>> 596: // - SharedArchiveFile is not specified and the VM doesn't have a compatible default archive
>>> 597:
>>> 598: #define __THEMSG " is unsupported when base CDS archive is not loaded. Run with -Xlog:cds for more info."
>>
>> Do we want to start transitioning existing `-Xlog:cds` options to be `:aot` options? I think making the switch would match out long term direction
>
> Yes, but I think we should do it only if `AOTClassLinking` is enabled. For legacy CDS we should continue use `-Xlog:cds`.
> I am using `-Xlog:aot+codecache` in AOT code caching.
I created [JDK-8354055 - Change "cds" logging tag to "aot"](https://bugs.openjdk.org/browse/JDK-8354055). There are documentation/compatibility issues so we need to do some planning.
This particular block of code is moved from dynamicArchive.cpp to cdsConfig.cpp and I kept the logging tag the same.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2033582112
From heidinga at openjdk.org Tue Apr 8 16:56:17 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 8 Apr 2025 16:56:17 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v3]
In-Reply-To: <jtv6CFfiBgokjjs43XMzZJgQFycEBUHLmaEKoBGtdGs=.fa34be7c-5913-490e-9513-6b1945137fef@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
<1ssLzAJVy1yrmNRCmTCz---JPV7_cLWOLwu0A3-yhZw=.02dbfc81-0a2e-4a4a-a7c1-bae8a93af621@github.com>
<PkIZM2m0oA6iu8tExWP69j4PceSjvUAXGUM0ciKIxTY=.29148411-d706-4882-8ef6-3ffa8806ec13@github.com>
<jtv6CFfiBgokjjs43XMzZJgQFycEBUHLmaEKoBGtdGs=.fa34be7c-5913-490e-9513-6b1945137fef@github.com>
Message-ID: <YpC4s4ykvr_Qmqv-iEUl5nnWRcOvQdtHTlToPm1iues=.4662c8ec-38f5-49e0-95a3-dc1c07f70b96@github.com>
On Tue, 8 Apr 2025 16:26:28 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> Yes, but I think we should do it only if `AOTClassLinking` is enabled. For legacy CDS we should continue use `-Xlog:cds`.
>> I am using `-Xlog:aot+codecache` in AOT code caching.
>
> I created [JDK-8354055 - Change "cds" logging tag to "aot"](https://bugs.openjdk.org/browse/JDK-8354055). There are documentation/compatibility issues so we need to do some planning.
>
> This particular block of code is moved from dynamicArchive.cpp to cdsConfig.cpp and I kept the logging tag the same.
Thanks @iklam. I agree with the approach of doing this in a separate issue.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24401#discussion_r2033640450
From kvn at openjdk.org Tue Apr 8 17:28:26 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 8 Apr 2025 17:28:26 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v3]
In-Reply-To: <OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<OGTv95XGW_pdW6ujqCb4TMDPgVmu6ebRSJ5qAl0xBOA=.cc614123-6633-40f4-bf3c-7b2f1b004e69@github.com>
Message-ID: <2ZMtE0qPWzJ1jSC31oFURQ2b7w3l7d8CJsXgmWauyiY=.e4a74cdf-d76a-4862-8966-eb26a0b57dac@github.com>
On Thu, 3 Apr 2025 20:31:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>>
>> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>>
>>
>> const char* CDSConfig::input_static_archive_path();
>> const char* CDSConfig::input_dynamic_archive_path();
>> const char* CDSConfig::output_archive_path();
>>
>>
>> This PR also cleans up the code by:
>> - renaming a few function to reflect what they actually do
>> - moving more "config" management code into cdsConfig.cpp
>>
>> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>>
>> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>
> @lmesnik comments
Looks good to me.
-------------
Marked as reviewed by kvn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2750854771
From jiangli at openjdk.org Tue Apr 8 18:55:21 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 8 Apr 2025 18:55:21 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK
In-Reply-To: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
Message-ID: <jjZAueaccfSfc47UxKShYOsF14E1mRbQ2FpzeMAehPo=.d3707219-f086-4bad-9a32-71433c0f499f@github.com>
On Tue, 8 Apr 2025 02:25:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:
> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
>
> ```
> JVMTI.agent_load [arguments]
> Loads JVMTI native agent.
> Impact: Low
> arguments:
> library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
> agent option: (Optional) Option string to pass the agent. (STRING, no default value)
> ```
>
> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
I discussed the `JVMTI.agent_load` issue on static support with @AlanBateman this morning as part of the hermetic Java meeting. @AlanBateman suggested considering adding an alternative diagnostic command or argument for the static (built-in) agent load support. We also discussed the use case of statically-linked dynamic (attached) native agents loaded by `jcmd` tool on static, and considerations for resolving (or clarifying) the `JVMTI.agent_load` static support at a later point when usage requirements were more clear. Outside the jtreg tests, I haven't run into any such usages yet.
Based on the discussion, I'll update this PR to skip the `LoadAgentDcmdTest` on static JDK for now.
I'll file a separate bug for the `JVMTI.agent_load` issue on static support so we can revisit that when things are more clear.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24497#issuecomment-2787388528
From jiangli at openjdk.org Tue Apr 8 19:09:02 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 8 Apr 2025 19:09:02 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK [v2]
In-Reply-To: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
Message-ID: <c63vQ_eEpIrCQsm_ATZrV1lg6EM0Cl6AXYXdeBTT9HQ=.67f7778b-14fb-4e77-95d4-f94ccedb876a@github.com>
> Please review this PR that changes `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` shared library if running on static JDK, instead just returns "libinstrument.<ext>" directly. Both test case #1 and #2 in `LoadAgentDcmdTest.run()` run ok on static JDK with the change:
>
> Commands:
> Test case #1: `JVMTI.agent_load libinstrument.so agent.jar`
> Test case #2: `JVMTI.agent_load libinstrument.so "agent.jar=foo=bar"`
>
> Additional notes/considerations:
>
> 1. I notice [JDKToolFinder.getJDKTool()](https://github.com/openjdk/jdk/blob/80ff7b9c9406c7845ecb3bc40910e92ccdd23ff2/test/lib/jdk/test/lib/JDKToolFinder.java#L41) is used by the test to find the `jcmd` tool. `JDKToolFinder.getJDKTool()` looks for the requested tool in both `test.jdk` and `compile.jdk`. When running the jtreg test on static JDK, it's able to locate the `jcmd` from `compile.jdk` even though the static JDK binary (`test.jdk`) does not provide the tool. For tools used by jtreg tests at runtime, how about change to always do that?
>
> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
>
> JVMTI.agent_load [arguments]
> Loads JVMTI native agent.
> Impact: Low
> arguments:
> library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
> agent option: (Optional) Option string to pass the agent. (STRING, no default value)
>
> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
Skip LoadAgentDcmdTest on static JDK.
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24497/files
- new: https://git.openjdk.org/jdk/pull/24497/files/1e61a0dd..3b4ef50c
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24497&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24497&range=00-01
Stats: 7 lines in 1 file changed: 1 ins; 6 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/24497.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24497/head:pull/24497
PR: https://git.openjdk.org/jdk/pull/24497
From jiangli at openjdk.org Tue Apr 8 19:35:23 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 8 Apr 2025 19:35:23 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK [v2]
In-Reply-To: <c63vQ_eEpIrCQsm_ATZrV1lg6EM0Cl6AXYXdeBTT9HQ=.67f7778b-14fb-4e77-95d4-f94ccedb876a@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
<c63vQ_eEpIrCQsm_ATZrV1lg6EM0Cl6AXYXdeBTT9HQ=.67f7778b-14fb-4e77-95d4-f94ccedb876a@github.com>
Message-ID: <bjrNGqhlw5hz-_BBGOtAvZdAEErgmE0tk7iuOoEl2JY=.0d5265d8-a877-4c35-a242-2bc4b6febc78@github.com>
On Tue, 8 Apr 2025 19:09:02 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:
>> Please review this PR that changes `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` shared library if running on static JDK, instead just returns "libinstrument.<ext>" directly. Both test case #1 and #2 in `LoadAgentDcmdTest.run()` run ok on static JDK with the change:
>>
>> Commands:
>> Test case #1: `JVMTI.agent_load libinstrument.so agent.jar`
>> Test case #2: `JVMTI.agent_load libinstrument.so "agent.jar=foo=bar"`
>>
>> Additional notes/considerations:
>>
>> 1. I notice [JDKToolFinder.getJDKTool()](https://github.com/openjdk/jdk/blob/80ff7b9c9406c7845ecb3bc40910e92ccdd23ff2/test/lib/jdk/test/lib/JDKToolFinder.java#L41) is used by the test to find the `jcmd` tool. `JDKToolFinder.getJDKTool()` looks for the requested tool in both `test.jdk` and `compile.jdk`. When running the jtreg test on static JDK, it's able to locate the `jcmd` from `compile.jdk` even though the static JDK binary (`test.jdk`) does not provide the tool. For tools used by jtreg tests at runtime, how about change to always do that?
>>
>> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
>>
>> JVMTI.agent_load [arguments]
>> Loads JVMTI native agent.
>> Impact: Low
>> arguments:
>> library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
>> agent option: (Optional) Option string to pass the agent. (STRING, no default value)
>>
>> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>
> Skip LoadAgentDcmdTest on static JDK.
I filed https://bugs.openjdk.org/browse/JDK-8354069.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24497#issuecomment-2787473905
From vklang at openjdk.org Tue Apr 8 20:09:25 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 8 Apr 2025 20:09:25 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
delayed task handling
In-Reply-To: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
Message-ID: <64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
>
> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
>
> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
>
> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.
src/java.base/share/classes/java/lang/VirtualThread.java line 889:
> 887: private void parkTimeoutExpired() {
> 888: assert !VirtualThread.currentThread().isVirtual();
> 889: if (!getAndSetParkPermit(true)
@AlanBateman Would it make sense to test whether the park-permit is false before the LOCK XCHG?
src/java.base/share/classes/java/lang/VirtualThread.java line 1455:
> 1453: return pool.schedule(command, delay, unit);
> 1454: } else {
> 1455: return DelayedTaskSchedulers.schedule(command, delay, unit);
@AlanBateman Would it make sense to test if the Scheduler implements ScheduledExecutorService?
src/java.base/share/classes/java/lang/VirtualThread.java line 1462:
> 1460: * Supports scheduling a runnable task to run after a delay. It uses a number
> 1461: * of ScheduledThreadPoolExecutor instances to reduce contention on the delayed
> 1462: * work queue used. This class is used when using a custom scheduler.
@AlanBateman It might make sense to instead require a custom Scheduler to implement ScheduledExecutorService? ?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2033942539
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2033943663
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2033944680
From lmesnik at openjdk.org Wed Apr 9 00:06:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 9 Apr 2025 00:06:41 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
Message-ID: <mpAfFDC-C3uEgT4hCJvfWgrO517Tne0FNvcKKrMU6d4=.610bf4f1-4697-4ed3-8095-d7b3b2b4dff0@github.com>
On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
>> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
>> It has always done a manual "root plus pid plus extension" on the default filename only, and
>> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>>
>>
>> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>
> - length checking update
> - Chris feedback
Marked as reviewed by lmesnik (Reviewer).
test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 100:
> 98: output.shouldContain("Dumping heap to " + type + ".hprof");
> 99: File dump = new File(heapdumpFilename);
> 100: Asserts.assertTrue(dump.exists() && dump.isFile(), "Could not find dump file " + dump.getAbsolutePath());
I. think you could just update the test to use
heapdumpFilename = type + ".%p.hprof";
we don't need test twice, it is quite expensive.
test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 115:
> 113: output.stdoutShouldNotBeEmpty();
> 114: String actualHeapdumpFilename = type + "." + output.pid() + ".hprof";
> 115: output.shouldContain("Dumping heap to " + actualHeapdumpFilename);
This better to be something like expectedlHeapdumpFilename and
"Expected heap dump file".
Not very important, but make log cleaner.
-------------
PR Review: https://git.openjdk.org/jdk/pull/24482#pullrequestreview-2751644078
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034187020
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034189152
From iklam at openjdk.org Wed Apr 9 02:18:41 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Apr 2025 02:18:41 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v4]
In-Reply-To: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
Message-ID: <lYrJW4jpcsl8E9t9j2ZB-JllWi1BoRcG1DAQ5cX4Wtw=.eed961b5-49d3-471a-a16b-db114b6b10c7@github.com>
> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>
> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>
>
> const char* CDSConfig::input_static_archive_path();
> const char* CDSConfig::input_dynamic_archive_path();
> const char* CDSConfig::output_archive_path();
>
>
> This PR also cleans up the code by:
> - renaming a few function to reflect what they actually do
> - moving more "config" management code into cdsConfig.cpp
>
> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>
> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
- Merge branch 'master' into 8353597-refactor-aot-cache-input-output
- @lmesnik comments
- more clean up
- Minimized changes in ergo_init_classic_archive_paths()
- Clean up CDS input/output path handling
- Refactored CollectClassesForLinking for simplification
- Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache
- Reverted some fixes in systemDictionaryShared.cpp that causes test failures
- 8353014: Exclude AOT tooling classes from AOT cache
-------------
Changes: https://git.openjdk.org/jdk/pull/24401/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24401&range=03
Stats: 309 lines in 15 files changed: 161 ins; 55 del; 93 mod
Patch: https://git.openjdk.org/jdk/pull/24401.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24401/head:pull/24401
PR: https://git.openjdk.org/jdk/pull/24401
From fyang at openjdk.org Wed Apr 9 04:02:29 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 9 Apr 2025 04:02:29 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@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>
<1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
Message-ID: <9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
On Fri, 28 Mar 2025 06:53:15 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> 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?
Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788216103
From asmehra at openjdk.org Wed Apr 9 04:06:30 2025
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Wed, 9 Apr 2025 04:06:30 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v4]
In-Reply-To: <lYrJW4jpcsl8E9t9j2ZB-JllWi1BoRcG1DAQ5cX4Wtw=.eed961b5-49d3-471a-a16b-db114b6b10c7@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<lYrJW4jpcsl8E9t9j2ZB-JllWi1BoRcG1DAQ5cX4Wtw=.eed961b5-49d3-471a-a16b-db114b6b10c7@github.com>
Message-ID: <TXjchyvEZKBwXw5PH1Tpq16ZUitWrb1STRFhgqzLDp0=.54359946-071a-464f-84c4-74e58d5fc6ae@github.com>
On Wed, 9 Apr 2025 02:18:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>>
>> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>>
>>
>> const char* CDSConfig::input_static_archive_path();
>> const char* CDSConfig::input_dynamic_archive_path();
>> const char* CDSConfig::output_archive_path();
>>
>>
>> This PR also cleans up the code by:
>> - renaming a few function to reflect what they actually do
>> - moving more "config" management code into cdsConfig.cpp
>>
>> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>>
>> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>
> - Merge branch 'master' into 8353597-refactor-aot-cache-input-output
> - @lmesnik comments
> - more clean up
> - Minimized changes in ergo_init_classic_archive_paths()
> - Clean up CDS input/output path handling
> - Refactored CollectClassesForLinking for simplification
> - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache
> - Reverted some fixes in systemDictionaryShared.cpp that causes test failures
> - 8353014: Exclude AOT tooling classes from AOT cache
lgtm
-------------
Marked as reviewed by asmehra (Committer).
PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2751975775
From alanb at openjdk.org Wed Apr 9 05:59:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 05:59:32 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
delayed task handling
In-Reply-To: <64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
<64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
Message-ID: <tjxADKcb5KEMEhlzWlNu43C3xZecT2EnxJ_9jJSjdgc=.d5a59178-242f-4ee4-883a-706ab4a48e8b@github.com>
On Tue, 8 Apr 2025 20:05:26 GMT, Viktor Klang <vklang at openjdk.org> wrote:
>> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
>>
>> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
>>
>> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
>>
>> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.
>
> src/java.base/share/classes/java/lang/VirtualThread.java line 889:
>
>> 887: private void parkTimeoutExpired() {
>> 888: assert !VirtualThread.currentThread().isVirtual();
>> 889: if (!getAndSetParkPermit(true)
>
> @AlanBateman Would it make sense to test whether the park-permit is false before the LOCK XCHG?
It already does, no CAS if the current value is the new value.
> src/java.base/share/classes/java/lang/VirtualThread.java line 1455:
>
>> 1453: return pool.schedule(command, delay, unit);
>> 1454: } else {
>> 1455: return DelayedTaskSchedulers.schedule(command, delay, unit);
>
> @AlanBateman Would it make sense to test if the Scheduler implements ScheduledExecutorService?
Not for now. If a custom scheduler feature is exposed some time then we can think about this topic, it may or may be that the custom scheduler supports delayed tasks.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034500634
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034500533
From rehn at openjdk.org Wed Apr 9 06:34:30 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 9 Apr 2025 06:34:30 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@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>
<1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
<9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
Message-ID: <in1ARdIEH4e0gSr8cKGjMt7G8tAPHQ0Ejq6tmHvqcbA=.52d947fb-f5ac-4e9b-9886-21608fffe3dd@github.com>
On Wed, 9 Apr 2025 03:57:10 GMT, Fei Yang <fyang at openjdk.org> wrote:
> > 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?
>
> Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.
Hey, thanks for considering.
The default qemu /proc/cpu do not contain any information about this being qemu.
And there is no standard way to find this out AFIAK.
Some platforms have target specific /proc/cpu and put qemu in there, but it have no standard format.
The whole proc -> uarch string -> jvm cpu string -> jtreg require is qemu/linux-user/riscv specific.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788434073
From stuefe at openjdk.org Wed Apr 9 06:46:35 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Apr 2025 06:46:35 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
Message-ID: <1hCrzMxrXFxiNGtP2T6tvgVhRyuCLRQpX5wsQNwCzNU=.a558b333-1057-4902-97f8-c8509ad85471@github.com>
On Tue, 8 Apr 2025 11:43:20 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
>> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
>> It has always done a manual "root plus pid plus extension" on the default filename only, and
>> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>>
>>
>> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
>
> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>
> - length checking update
> - Chris feedback
src/hotspot/share/services/heapDumper.cpp line 2760:
> 2758: if (dump_file_seq == 0) { // first time in, we initialize base_path
> 2759: // Set base path (name or directory, default or custom, without seq no), doing %p substitution.
> 2760: const char *path_src = (HeapDumpPath != nullptr && HeapDumpPath[0] != '\0') ? HeapDumpPath : dump_file_name;
Why do you expand the dump file name here?
If you want to minimize the expand calls, you could:
- append the unexpanded dump_file_name to the unexpanded HeapDumpPath
- expand
- create dir (extract the directory name by temporarily setting the the last '/' to '\0; create dir; restore '/')
now you are done.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034576102
From fyang at openjdk.org Wed Apr 9 07:35:40 2025
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 9 Apr 2025 07:35:40 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <in1ARdIEH4e0gSr8cKGjMt7G8tAPHQ0Ejq6tmHvqcbA=.52d947fb-f5ac-4e9b-9886-21608fffe3dd@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>
<1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
<9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
<in1ARdIEH4e0gSr8cKGjMt7G8tAPHQ0Ejq6tmHvqcbA=.52d947fb-f5ac-4e9b-9886-21608fffe3dd@github.com>
Message-ID: <z5T2KPlyovmIM2NY7dnZfQuc-KAHNdXuGZC5cqjMuaQ=.029e63f3-5e5b-4584-88fe-ac4c5a24f41d@github.com>
On Wed, 9 Apr 2025 06:31:55 GMT, Robbin Ehn <rehn at openjdk.org> wrote:
> > > 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?
> >
> >
> > Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.
>
> Hey, thanks for considering. The default qemu /proc/cpu do not contain any information about this being qemu. And there is no standard way to find this out AFIAK. Some platforms have target specific /proc/cpu and put qemu in there, but it have no standard format. The whole proc -> uarch string -> jvm cpu string -> jtreg require is qemu/linux-user/riscv specific.
Ah, I see. But I guess it won't bite us if we can't parse `qemu` in /proc/cpuinfo? I am not familiar with how qemu-user works. Can I expect this to work at least for some other CPUs supported by the JVM?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788626578
From vklang at openjdk.org Wed Apr 9 08:06:33 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 9 Apr 2025 08:06:33 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
delayed task handling
In-Reply-To: <tjxADKcb5KEMEhlzWlNu43C3xZecT2EnxJ_9jJSjdgc=.d5a59178-242f-4ee4-883a-706ab4a48e8b@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
<64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
<tjxADKcb5KEMEhlzWlNu43C3xZecT2EnxJ_9jJSjdgc=.d5a59178-242f-4ee4-883a-706ab4a48e8b@github.com>
Message-ID: <cCeNh0T_LZAF9cNrf4YjRdCJVSFg24BnUrKcBkJmLrc=.8dfdfce0-48dc-4147-9206-c02209a793b2@github.com>
On Wed, 9 Apr 2025 05:56:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 889:
>>
>>> 887: private void parkTimeoutExpired() {
>>> 888: assert !VirtualThread.currentThread().isVirtual();
>>> 889: if (!getAndSetParkPermit(true)
>>
>> @AlanBateman Would it make sense to test whether the park-permit is false before the LOCK XCHG?
>
> It already does, no CAS if the current value is the new value.
I meant the park permit. :)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034736102
From rehn at openjdk.org Wed Apr 9 08:09:42 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 9 Apr 2025 08:09:42 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v2]
In-Reply-To: <z5T2KPlyovmIM2NY7dnZfQuc-KAHNdXuGZC5cqjMuaQ=.029e63f3-5e5b-4584-88fe-ac4c5a24f41d@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>
<1pa1FDH5Z2quR3fE7o4qfZKwRrz8nXHbMSirSyiqhTw=.9c37d2a9-5b93-40dd-8b5a-a5822030ef48@github.com>
<9R7U8cL4aSOayHQzaXoTGx0nXSXqdkO4ZomONZnM0Ao=.c1c90e1c-3085-4656-911d-23c407cff74d@github.com>
<in1ARdIEH4e0gSr8cKGjMt7G8tAPHQ0Ejq6tmHvqcbA=.52d947fb-f5ac-4e9b-9886-21608fffe3dd@github.com>
<z5T2KPlyovmIM2NY7dnZfQuc-KAHNdXuGZC5cqjMuaQ=.029e63f3-5e5b-4584-88fe-ac4c5a24f41d@github.com>
Message-ID: <hlK7JsNDmIpwGJDVHVPUJPb6iCs_oXkbuQhjU-0LBlM=.39a5cf84-bfbf-441b-b70c-3cd05e6c3a55@github.com>
On Wed, 9 Apr 2025 07:29:01 GMT, Fei Yang <fyang at openjdk.org> wrote:
> > > > 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?
> > >
> > >
> > > Hi, That make sense to me. And it doesn't seem to me to be riscv-specific issue, but rather one with qemu-user. Maybe we should update the title and changes to reflect that? I sometimes see people testing with qemu for other CPU platforms as well like ppc, s390, etc. Guess they might be helped with this too.
> >
> >
> > Hey, thanks for considering. The default qemu /proc/cpu do not contain any information about this being qemu. And there is no standard way to find this out AFIAK. Some platforms have target specific /proc/cpu and put qemu in there, but it have no standard format. The whole proc -> uarch string -> jvm cpu string -> jtreg require is qemu/linux-user/riscv specific.
>
> Ah, I see. But I guess it won't bite us if we can't parse `qemu` in /proc/cpuinfo? I am not familiar with how qemu-user works. Can I expect this to work at least for some other CPUs supported by the JVM?
qemu-user, "uarch: qemu" in cpuinfo:
`[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond`
Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
`/proc/cpuinfo` do not contain uarch:
[0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond
We have no clue if this is emulated or on real hardware, tests will be executed.
Tests are only excluded if we know it's qemu-user.
Did that anwser your Q ?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2788717608
From alanb at openjdk.org Wed Apr 9 08:19:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 08:19:36 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
delayed task handling
In-Reply-To: <cCeNh0T_LZAF9cNrf4YjRdCJVSFg24BnUrKcBkJmLrc=.8dfdfce0-48dc-4147-9206-c02209a793b2@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
<64xe_dZIfIScyB_InbjJJn19DjAY_7qxmsB7FKKKIH4=.0c4ad76a-cbf8-475d-b3e8-6c2336ec1f29@github.com>
<tjxADKcb5KEMEhlzWlNu43C3xZecT2EnxJ_9jJSjdgc=.d5a59178-242f-4ee4-883a-706ab4a48e8b@github.com>
<cCeNh0T_LZAF9cNrf4YjRdCJVSFg24BnUrKcBkJmLrc=.8dfdfce0-48dc-4147-9206-c02209a793b2@github.com>
Message-ID: <RnSg4BjQE263mywQOrkiv7WPzcXL3rnBJaHSluKEDZw=.d6082086-e3d8-4abd-a776-5272d31004e2@github.com>
On Wed, 9 Apr 2025 08:03:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:
>> It already does, no CAS if the current value is the new value.
>
> I meant the park permit. :)
getAndSetParkPermit isn't changed in this PR. If the park permit is already granted then getAndSetParkPermit(true) doesn't do anything. More generally, parkTimeoutExpired is just a reduced unpark, only added so that we can do a lazy rather than internal submit for the less common case that the timeout expires.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24030#discussion_r2034760820
From sspitsyn at openjdk.org Wed Apr 9 08:20:34 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Apr 2025 08:20:34 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
Message-ID: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
Some specific implementation details can be added to the first PR comment.
Testing:
- Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
- the assert described above is fired if the fix of JDK-8352088 is removed
- the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
- Ran mach5 tiers 1-6
-------------
Commit messages:
- 8352773: JVMTI should disable events during java upcalls
Changes: https://git.openjdk.org/jdk/pull/24539/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24539&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8352773
Stats: 32 lines in 6 files changed: 30 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/24539.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24539/head:pull/24539
PR: https://git.openjdk.org/jdk/pull/24539
From alanb at openjdk.org Wed Apr 9 08:41:24 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 08:41:24 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <uC6wCKDPwLHdPU4pPfNs9RhDDYqpmrJoPAOL1_18gpM=.46f31307-bc74-47e1-b20e-1cb9ada6ec2b@github.com>
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
If this goes ahead then it allows for a discussion about changing JVMTI InterruptThread to invoke Thread.interrupt when the target is a platform thread. As you know, there is a long standing issue here where threads blocked on interruptible channels not being awakened by JVMTI InterruptThread.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24539#issuecomment-2788806930
From vklang at openjdk.org Wed Apr 9 08:46:36 2025
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 9 Apr 2025 08:46:36 GMT
Subject: RFR: 8351927: Change VirtualThread implementation to use use FJP
delayed task handling
In-Reply-To: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
Message-ID: <DMqCW8XmM-5MWr_M9mZeUzqQbtVFbxafd3z9-Rxgzi4=.36ca5967-fd94-4baf-b5da-d089c78d396e@github.com>
On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
>
> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
>
> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
>
> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.
Marked as reviewed by vklang (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24030#pullrequestreview-2752606260
From kevinw at openjdk.org Wed Apr 9 08:52:31 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Apr 2025 08:52:31 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <1hCrzMxrXFxiNGtP2T6tvgVhRyuCLRQpX5wsQNwCzNU=.a558b333-1057-4902-97f8-c8509ad85471@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
<1hCrzMxrXFxiNGtP2T6tvgVhRyuCLRQpX5wsQNwCzNU=.a558b333-1057-4902-97f8-c8509ad85471@github.com>
Message-ID: <MY64DsIgCH5JxTj4LJQo19C1WJouaz8ltF1xRM99vRY=.239385a9-ebfd-4af1-9c53-a4348b283289@github.com>
On Wed, 9 Apr 2025 06:43:20 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - length checking update
>> - Chris feedback
>
> src/hotspot/share/services/heapDumper.cpp line 2760:
>
>> 2758: if (dump_file_seq == 0) { // first time in, we initialize base_path
>> 2759: // Set base path (name or directory, default or custom, without seq no), doing %p substitution.
>> 2760: const char *path_src = (HeapDumpPath != nullptr && HeapDumpPath[0] != '\0') ? HeapDumpPath : dump_file_name;
>
> Why do you expand the dump file name here?
>
> If you want to minimize the expand calls, you could:
>
> - append the unexpanded dump_file_name to the unexpanded HeapDumpPath
> - expand
> - create dir (extract the directory name by temporarily setting the the last '/' to '\0; create dir; restore '/')
> now you are done.
It concerned me that we presume there is no %p in the directory/path. It might be tricky (get the pid, create a directory, before the first heap dump), but it's possible.
Trying to use an existing directory with a literal %p in it will fail, but we can't have this both ways, and should either honour the %p substitution fully, or not.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034820138
From kevinw at openjdk.org Wed Apr 9 09:34:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Apr 2025 09:34:02 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v3]
In-Reply-To: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
Message-ID: <i6vRX8dklQ5YhXf6-CW_IUwAwUv-SKgpwnnW4RvGxRs=.69c9d098-621e-4882-b951-e4d38d1436dc@github.com>
> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
> It has always done a manual "root plus pid plus extension" on the default filename only, and
> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>
>
> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
test feedback
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24482/files
- new: https://git.openjdk.org/jdk/pull/24482/files/c32e4ca4..40c67a0c
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=01-02
Stats: 24 lines in 1 file changed: 1 ins; 17 del; 6 mod
Patch: https://git.openjdk.org/jdk/pull/24482.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482
PR: https://git.openjdk.org/jdk/pull/24482
From kevinw at openjdk.org Wed Apr 9 09:34:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Apr 2025 09:34:02 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v2]
In-Reply-To: <mpAfFDC-C3uEgT4hCJvfWgrO517Tne0FNvcKKrMU6d4=.610bf4f1-4697-4ed3-8095-d7b3b2b4dff0@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<hyFyLi68ISLz-aUGJpEOW8CDvukNKdONbe-Bcx70aE8=.b38be7ff-07d4-47c8-89c1-43eddff9727b@github.com>
<mpAfFDC-C3uEgT4hCJvfWgrO517Tne0FNvcKKrMU6d4=.610bf4f1-4697-4ed3-8095-d7b3b2b4dff0@github.com>
Message-ID: <M2lmRWzO-Pqz_MwqZxOcHvv5ftIEDwTo5F2y4oRhjwo=.5ca7f5e6-a4d0-40fe-af0e-2264e5683595@github.com>
On Wed, 9 Apr 2025 00:00:28 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
>> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision:
>>
>> - length checking update
>> - Chris feedback
>
> test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 100:
>
>> 98: output.shouldContain("Dumping heap to " + type + ".hprof");
>> 99: File dump = new File(heapdumpFilename);
>> 100: Asserts.assertTrue(dump.exists() && dump.isFile(), "Could not find dump file " + dump.getAbsolutePath());
>
> I. think you could just update the test to use
> heapdumpFilename = type + ".%p.hprof";
> we don't need test twice, it is quite expensive.
sure, it's a few seconds but we can save that time 8-)
> test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java line 115:
>
>> 113: output.stdoutShouldNotBeEmpty();
>> 114: String actualHeapdumpFilename = type + "." + output.pid() + ".hprof";
>> 115: output.shouldContain("Dumping heap to " + actualHeapdumpFilename);
>
> This better to be something like expectedlHeapdumpFilename and
> "Expected heap dump file".
>
> Not very important, but make log cleaner.
sure, done!
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034931003
PR Review Comment: https://git.openjdk.org/jdk/pull/24482#discussion_r2034931425
From sspitsyn at openjdk.org Wed Apr 9 09:56:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Apr 2025 09:56:29 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <uC6wCKDPwLHdPU4pPfNs9RhDDYqpmrJoPAOL1_18gpM=.46f31307-bc74-47e1-b20e-1cb9ada6ec2b@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<uC6wCKDPwLHdPU4pPfNs9RhDDYqpmrJoPAOL1_18gpM=.46f31307-bc74-47e1-b20e-1cb9ada6ec2b@github.com>
Message-ID: <ZFRQv0764JiPiMhaga9T-bJCMkzStbdcy7vieMQNGBU=.ceb21090-d256-40b0-a72a-54a2fb51a8ca@github.com>
On Wed, 9 Apr 2025 08:39:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> If this goes ahead then it allows for a discussion about changing JVMTI InterruptThread to invoke Thread.interrupt when the target is a platform thread. As you know, there is a long standing issue here where threads blocked on interruptible channels not being awakened by JVMTI InterruptThread.
Yes, this fix is already including an update for interrupts. I'll add a comment with the fix details tomorrow.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24539#issuecomment-2789083462
From ihse at openjdk.org Wed Apr 9 10:31:39 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 10:31:39 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: <PWGxjU1jSJO-8yCWpIMzAjqku3_27s8Gd93rjztJlng=.fe1ff3c3-bea5-447e-9e3f-10930f0b95ec@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 .
Wait, `LOW` is `-O2`? ? I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. *sigh*
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789200299
From mbaesken at openjdk.org Wed Apr 9 10:44:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Apr 2025 10:44:39 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: <WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@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 .
> Wait, `LOW` is `-O2`? ? I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. _sigh_
Yes see
https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L310
on gcc/clang `C_O_FLAG_NORM="-O2"`
and for LOW optimization level of a lib, we use the FLAG_NORM , see
https://github.com/openjdk/jdk/blob/master/make/common/native/Flags.gmk#L46
else ifeq ($$($1_OPTIMIZATION), LOW)
$1_OPT_CFLAGS := $(C_O_FLAG_NORM)
$1_OPT_CXXFLAGS := $(CXX_O_FLAG_NORM)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789230263
From stuefe at openjdk.org Wed Apr 9 10:45:32 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 9 Apr 2025 10:45:32 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v3]
In-Reply-To: <i6vRX8dklQ5YhXf6-CW_IUwAwUv-SKgpwnnW4RvGxRs=.69c9d098-621e-4882-b951-e4d38d1436dc@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<i6vRX8dklQ5YhXf6-CW_IUwAwUv-SKgpwnnW4RvGxRs=.69c9d098-621e-4882-b951-e4d38d1436dc@github.com>
Message-ID: <IpC4zr9JLXC3LGNCrGzV52GQI-3EuwssNpsWKMuntoY=.e78dcc3f-ee90-419f-bfda-87317722725a@github.com>
On Wed, 9 Apr 2025 09:34:02 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
>> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
>> It has always done a manual "root plus pid plus extension" on the default filename only, and
>> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>>
>>
>> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
>
> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>
> test feedback
Looks good to me.
-------------
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24482#pullrequestreview-2753028819
From alanb at openjdk.org Wed Apr 9 11:03:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 11:03:33 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK [v2]
In-Reply-To: <c63vQ_eEpIrCQsm_ATZrV1lg6EM0Cl6AXYXdeBTT9HQ=.67f7778b-14fb-4e77-95d4-f94ccedb876a@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
<c63vQ_eEpIrCQsm_ATZrV1lg6EM0Cl6AXYXdeBTT9HQ=.67f7778b-14fb-4e77-95d4-f94ccedb876a@github.com>
Message-ID: <XCR0sEtqdmsW8-repel2IktA5p_dEBHO2WDCRUlRH4M=.0d6d66ec-c147-4398-bab1-175cf86a42da@github.com>
On Tue, 8 Apr 2025 19:09:02 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:
>> Please review this PR that changes `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` shared library if running on static JDK, instead just returns "libinstrument.<ext>" directly. Both test case #1 and #2 in `LoadAgentDcmdTest.run()` run ok on static JDK with the change:
>>
>> Commands:
>> Test case #1: `JVMTI.agent_load libinstrument.so agent.jar`
>> Test case #2: `JVMTI.agent_load libinstrument.so "agent.jar=foo=bar"`
>>
>> Additional notes/considerations:
>>
>> 1. I notice [JDKToolFinder.getJDKTool()](https://github.com/openjdk/jdk/blob/80ff7b9c9406c7845ecb3bc40910e92ccdd23ff2/test/lib/jdk/test/lib/JDKToolFinder.java#L41) is used by the test to find the `jcmd` tool. `JDKToolFinder.getJDKTool()` looks for the requested tool in both `test.jdk` and `compile.jdk`. When running the jtreg test on static JDK, it's able to locate the `jcmd` from `compile.jdk` even though the static JDK binary (`test.jdk`) does not provide the tool. For tools used by jtreg tests at runtime, how about change to always do that?
>>
>> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
>>
>> JVMTI.agent_load [arguments]
>> Loads JVMTI native agent.
>> Impact: Low
>> arguments:
>> library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
>> agent option: (Optional) Option string to pass the agent. (STRING, no default value)
>>
>> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>
> Skip LoadAgentDcmdTest on static JDK.
I assume you've bump the copyright header before integrating.
-------------
Marked as reviewed by alanb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24497#pullrequestreview-2753076032
From kevinw at openjdk.org Wed Apr 9 11:04:26 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Apr 2025 11:04:26 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v4]
In-Reply-To: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
Message-ID: <r-mzgZ14vDc2RAPCwLTEKiRcm6e6pgfSso4bFLGoARc=.65040692-d7ee-435d-8225-6909447d9a2b@github.com>
> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
> It has always done a manual "root plus pid plus extension" on the default filename only, and
> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>
>
> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
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 five additional commits since the last revision:
- Merge remote-tracking branch 'upstream/master' into HeapDumpPath_pid
- test feedback
- length checking update
- Chris feedback
- 8353727: HeapDumpPath doesn't expand %p
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24482/files
- new: https://git.openjdk.org/jdk/pull/24482/files/40c67a0c..09f66542
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24482&range=02-03
Stats: 11976 lines in 335 files changed: 8329 ins; 2524 del; 1123 mod
Patch: https://git.openjdk.org/jdk/pull/24482.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24482/head:pull/24482
PR: https://git.openjdk.org/jdk/pull/24482
From ihse at openjdk.org Wed Apr 9 12:29:40 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 12:29:40 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: <zkNm-R-KDCm8Hqsi3ghv5tVwifcgczCFiZqpxQrGOrM=.c3ab09df-b0c2-4059-811e-92df026c3661@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 .
O.M.G.
This is sooo messed up. I am thinking about making a special build where I set everything to -O3 and another where I set everything to -Os and just see what difference it makes in size and performance tests, and then suggest just going for one of them at the general rule (with exceptions for individual libraries, if needed).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789534753
From ihse at openjdk.org Wed Apr 9 12:33:35 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 12:33:35 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: <zrqZ2uHwdLGZ-8N_LY9G-wVV2NeFVRqIlzQDeQgI4h8=.8e124a7f-e919-486c-9c1d-2358d6a83bec@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 .
We also really must skip the dichotomy between `C_O_FLAG` and `OPTIMIZATION`, it just makes no sense whatsoever.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789545415
From ihse at openjdk.org Wed Apr 9 12:36:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 12:36:37 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: <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@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 .
I'd like to move to a world where we basically have just two optimization levels, "size" and "speed", and libraries do not in general have the level specified, so it falls back on a default, which could then be set by configure. For individual libraries we might need to override the default value, if we know that certain compilers make a mess of certain optimization levels, or if some libraries are especially performance sensitive. (Making hotspot `-Os` would certainly never make any sense, for example.)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789552092
From alanb at openjdk.org Wed Apr 9 12:39:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 12:39:48 GMT
Subject: Integrated: 8351927: Change VirtualThread implementation to use use
FJP delayed task handling
In-Reply-To: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
References: <7vE97S4zy2S1vuRwEapE4k9ZScS6yTJBQWyKymjdc0g=.5551d6d6-68ad-446e-84c7-70fd57fa57a6@github.com>
Message-ID: <I60xAuNc48bT98Ao4nmbHk3TY2DEj0gTmhyfikBnQyw=.a30671f5-3f0c-4209-8303-cbe9fd272d63@github.com>
On Thu, 13 Mar 2025 10:48:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> Follow up to JDK-8319447 to change the VirtualThread implementation to use FJP's delayed task handling.
>
> The SPTE based implementation is not removed. It will continue to be used by tests. If custom schedulers are exposed in the future then they will use this implementation.
>
> For timed-Object.wait, waitTimeoutExpired is changed to use lazySubmit to avoid signalling and increase the chance that the unparked virtual thread will continue on the current carrier. For timed-park, the timeout task is changed to reduced form of unpark that also uses lazySubmit, for the same reason.
>
> `jcmd Thread.vthread_scheduler` is changed to no longer print the delay schedulers. Instead, the delayed task count will appear in the default scheduler output.
This pull request has now been integrated.
Changeset: 6c93ad42
Author: Alan Bateman <alanb at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/6c93ad42f38b49ea96155340c4b6bbedfcef2a90
Stats: 405 lines in 8 files changed: 332 ins; 41 del; 32 mod
8351927: Change VirtualThread implementation to use use FJP delayed task handling
Reviewed-by: vklang
-------------
PR: https://git.openjdk.org/jdk/pull/24030
From duke at openjdk.org Wed Apr 9 13:24:33 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 9 Apr 2025 13:24:33 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v4]
In-Reply-To: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
Message-ID: <5MzHrfRc-pu8J5vQdmeeuk4HxP7uumhhVfELVs_VRwU=.4d86b907-a8e8-4bbd-98cb-892491b5c2ad@github.com>
> ### Update:
> After some discussion it was decided it's not necessary to expand the lock scope for reserve/commit. Instead, we are opting to add comments explaining the reasons for locking and the conditions to avoid which could lead to races. Some of the new tests can be kept because they are general enough to be useful outside of this context.
>
> ### 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...
Robert Toyonaga has updated the pull request incrementally with four additional commits since the last revision:
- Update test/hotspot/gtest/runtime/test_os.cpp
Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
- Update test/hotspot/gtest/runtime/test_os.cpp
Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
- Update test/hotspot/gtest/runtime/test_os.cpp
Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
- Update test/hotspot/gtest/runtime/test_os.cpp
Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24084/files
- new: https://git.openjdk.org/jdk/pull/24084/files/5c23a76a..813a1e49
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=02-03
Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 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 duke at openjdk.org Wed Apr 9 13:24:35 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 9 Apr 2025 13:24:35 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v3]
In-Reply-To: <eARbfibOFKAIkTkZjRt4n49yHoVteBYpLlKWGf8-QyU=.62f0cae0-26ee-45b9-ac92-7c8b94462877@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<pENA7rNLFax4lrCdieDSNxFQ58RsHjmCkj2UWFb0tTo=.87bb0fc6-1cd4-49ad-9ce0-170273fbd8e8@github.com>
<eARbfibOFKAIkTkZjRt4n49yHoVteBYpLlKWGf8-QyU=.62f0cae0-26ee-45b9-ac92-7c8b94462877@github.com>
Message-ID: <TiRpua5zrCZE-xl7ZQWpiRk7ZTkPfpsT8BMmDfUtkwA=.59342fec-9f9d-4770-937e-d4652272497f@github.com>
On Tue, 8 Apr 2025 14:08:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>>
>> exclude file mapping tests on AIX.
>
> src/hotspot/share/runtime/os.cpp line 2206:
>
>> 2204: // when it is actually committed. The opposite scenario is not guarded against. pd_commit_memory and
>> 2205: // record_virtual_memory_commit do not happen atomically. We assume that there is some external synchronization
>> 2206: // that prevents a region from being uncommitted before it is finished being committed.
>
> It's not a requirement, but you get kudos from me if you keep comments lines below 80 lines. I typically don't like code to be 80 lines, but comments tend to be nicer if they are.
Ok I'll try to shorten these comments a bit
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24084#discussion_r2035360006
From duke at openjdk.org Wed Apr 9 13:43:01 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 9 Apr 2025 13:43:01 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock [v5]
In-Reply-To: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
Message-ID: <GXk4Si4MuEFTRy3ytdoeFzQUs8biJYecFGaElzcGgf0=.728757b9-99d3-4995-8e1c-1dc49bd60ada@github.com>
> ### Update:
> After some discussion it was decided it's not necessary to expand the lock scope for reserve/commit. Instead, we are opting to add comments explaining the reasons for locking and the conditions to avoid which could lead to races. Some of the new tests can be kept because they are general enough to be useful outside of this context.
>
> ### 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...
Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
improve tests and comments
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24084/files
- new: https://git.openjdk.org/jdk/pull/24084/files/813a1e49..7b7263b2
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=04
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24084&range=03-04
Stats: 23 lines in 2 files changed: 1 ins; 8 del; 14 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 jsikstro at openjdk.org Wed Apr 9 13:56:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 9 Apr 2025 13:56:53 GMT
Subject: RFR: 8350441: ZGC: Overhaul Page Allocation
Message-ID: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
# Background
This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
# Why a Mapped Cache?
The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
# Fragmentation
Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
## Virtual Memory Shuffling
In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with virtual memory. When harvesting memory, which needs to be remapped, new contiguous virtual memory must first be claimed. We have now added a feature in which the harvested memory can be re-used to improve the likelihood of finding a contiguous range. Additionally, we have re-designed the defragmentation policy so that Large pages are always defragmented upon being freed. When freed, they are broken down and remapped into lower address space, in the hopes of "filling holes" and creating more contiguous ranges.
# NUMA and Partitions
In the current policy, ZGC interleaves memory across all NUMA nodes with a granularity of ZGranuleSize (2MB), which is the same size as a Small page. As a result, Small pages will end up on a single, preferably local, NUMA node, whilst larger allocations will (likely) end up on multiple NUMA nodes. In the new design, the policy is to prefer allocating *all* allocation sizes to the local NUMA node whenever possible. As an effect, ZGC may be able to extract better performance from NUMA systems.
To support local NUMA allocations, the Page Allocator, and in turn the Java heap, has been split up into what we refer to as Partitions. A partition keeps track of its own heap size and Mapped Cache, allowing it to only handle memory that is associated with its own share of the heap. The number of partitions is currently the same as the number of NUMA nodes. On non-NUMA systems, only a single partition is kept track of.
The introduction of partitions also establishes a foundation for more fine-grained control over the heap, paving the way for future enhancements, both NUMA possibilities and new features, such as Thread-Local GC.
# Defragmentation (Unmapping Memory)
Up until now, ZGC has unmapped memory asynchronously in a separate thread. The benefit of this is that other threads do not need to take a latency hit when unmapping memory. The main dependency on asynchronous unmapping is when harvesting, especially from a mutator thread, where synchronous unmapping could lead to unwanted latency.
With the introduction of the Mapped Cache, and by moving defragmentation away from mutator threads to the GC, asynchronous unmapping is no longer necessary to meet our latency goals. Instead, memory is now unmapped synchronously. The number of times memory is defragmented for page allocations has been reduced significantly. However, memory for Small pages never needs to be defragmented at all. For Large pages, memory defragmentation has little effect on the total latency, as they are costly to allocate anyways. For Medium pages, we have plans for future enhancements where memory is defragmented even less, or not at all.
For clarity: with the removal of asynchronous unmapping, we have removed the ZUnmapper thread and ZUnmap JFR event.
# Multi-Mapped Memory
Asynchronous unmapping has so far been possible because ZGC is backed by shared memory (on Linux), which allows memory to be multi-mapped. This is an artifact from non-generational ZGC, which used multi-mapping in its core design (See [this](https://wiki.openjdk.org/display/zgc/Pointer+Metadata+using+Multi-Mapped+memory) resource for more info). A goal we have in ZGC is to move from shared memory to anonymous memory. There are multiple benefits with anonymous memory, one of them being easier configuration for Transparent Huge Pages (OS pages). Anonymous memory doesn't support multi-mapped memory, and would be blocked by the asynchronous unmapping feature. However, with the removal of asynchronous unmapping, we are now better prepared for transitioning to anonymous memory.
# Additional Notes
This RFE comes with our own implementation of a red-black tree for the Mapped Cache. Another red-black tree was recently introduced by C. Norrbin in [JDK-8345314](https://bugs.openjdk.org/browse/JDK-8345314) (and enhanced in [JDK-8349211](https://bugs.openjdk.org/browse/JDK-8349211)). Our goal is to initially integrate with our implementation, but remove our implementation in favor of Norrbin's tree in a future RFE. The reason we have our own tree implementation is because Norrbin's tree was not finished during the time we were developing and testing this RFE.
Some new additions have been made to keep the current functionality in the Serviceability Agent (SA).
# Testing
* Oracle's tiers 1-8
* We have added a small set of new tests, both gtests and jtreg tests, to test new functionality
# Performance
* Improvements in tail latency in SPECjbb2015.
* Improvements when using small OS pages in combination with NUMA.
* Small increase in the time it takes to run a GC. This is because some work has been moved from mutator threads to only be done in GC threads. This should not affect the total run-time of a program as the total work remains the same, but mutator latency is improved.
* Other suitable benchmarks show no significant improvements or regressions.
-------------
Commit messages:
- Whitespace fix in zunittest.hpp
- Copyright years
- 8350441: ZGC: Overhaul Page Allocation
Changes: https://git.openjdk.org/jdk/pull/24547/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24547&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8350441
Stats: 12052 lines in 118 files changed: 7936 ins; 3218 del; 898 mod
Patch: https://git.openjdk.org/jdk/pull/24547.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24547/head:pull/24547
PR: https://git.openjdk.org/jdk/pull/24547
From kvn at openjdk.org Wed Apr 9 14:01:44 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Apr 2025 14:01:44 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v4]
In-Reply-To: <lYrJW4jpcsl8E9t9j2ZB-JllWi1BoRcG1DAQ5cX4Wtw=.eed961b5-49d3-471a-a16b-db114b6b10c7@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<lYrJW4jpcsl8E9t9j2ZB-JllWi1BoRcG1DAQ5cX4Wtw=.eed961b5-49d3-471a-a16b-db114b6b10c7@github.com>
Message-ID: <9g5m1aRjX_bOUqojs3da5pKPapimb1lnYxqdA92l8jk=.03e0aa78-bc7b-419a-814a-3104f300bf13@github.com>
On Wed, 9 Apr 2025 02:18:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:
>> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>>
>> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>>
>>
>> const char* CDSConfig::input_static_archive_path();
>> const char* CDSConfig::input_dynamic_archive_path();
>> const char* CDSConfig::output_archive_path();
>>
>>
>> This PR also cleans up the code by:
>> - renaming a few function to reflect what they actually do
>> - moving more "config" management code into cdsConfig.cpp
>>
>> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>>
>> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>
> - Merge branch 'master' into 8353597-refactor-aot-cache-input-output
> - @lmesnik comments
> - more clean up
> - Minimized changes in ergo_init_classic_archive_paths()
> - Clean up CDS input/output path handling
> - Refactored CollectClassesForLinking for simplification
> - Merge branch 'master' into 8353014-exclude-tooling-classes-from-aot-cache
> - Reverted some fixes in systemDictionaryShared.cpp that causes test failures
> - 8353014: Exclude AOT tooling classes from AOT cache
Re-approved.
-------------
Marked as reviewed by kvn (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24401#pullrequestreview-2753597060
From mbaesken at openjdk.org Wed Apr 9 14:20:40 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 9 Apr 2025 14:20:40 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
<cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
Message-ID: <XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>
On Wed, 9 Apr 2025 12:33:26 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
> Making hotspot -Os would certainly never make any sense, for example
We even have this (jvm feature opt-size)
https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L197
but it is not widely used afaik.
I think in the past it was used for certain small deployments (and a few very performance sensitive files , see the list from the link, still use 'speed optimization' ).
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2789899406
From kevinw at openjdk.org Wed Apr 9 14:51:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Apr 2025 14:51:48 GMT
Subject: RFR: 8353727: HeapDumpPath doesn't expand %p [v4]
In-Reply-To: <r-mzgZ14vDc2RAPCwLTEKiRcm6e6pgfSso4bFLGoARc=.65040692-d7ee-435d-8225-6909447d9a2b@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
<r-mzgZ14vDc2RAPCwLTEKiRcm6e6pgfSso4bFLGoARc=.65040692-d7ee-435d-8225-6909447d9a2b@github.com>
Message-ID: <R-tPxqv-peFX0FXE7zrHC6tvD-Jgoqxl1Pc_C3qogm8=.21037a62-c4c4-4ad3-996f-9e5932ee9dc1@github.com>
On Wed, 9 Apr 2025 11:04:26 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
>> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
>> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
>> It has always done a manual "root plus pid plus extension" on the default filename only, and
>> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>>
>>
>> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
>
> 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 five additional commits since the last revision:
>
> - Merge remote-tracking branch 'upstream/master' into HeapDumpPath_pid
> - test feedback
> - length checking update
> - Chris feedback
> - 8353727: HeapDumpPath doesn't expand %p
Thanks for the reviews!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24482#issuecomment-2789998024
From kevinw at openjdk.org Wed Apr 9 14:51:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 9 Apr 2025 14:51:48 GMT
Subject: Integrated: 8353727: HeapDumpPath doesn't expand %p
In-Reply-To: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
References: <mslp94k5bQj4mHHukSCeiyDr6MjBfqAaS3zt9LKnEmk=.e4fec265-a487-4727-ac9b-e20b55dbf9f3@github.com>
Message-ID: <ftHfCoDgtcgrG_yEGjrZnVdL12DLTLKGoFcetyv1e_Y=.eab4201a-adb1-42b3-b99f-2b9eefc9530d@github.com>
On Mon, 7 Apr 2025 09:05:34 GMT, Kevin Walls <kevinw at openjdk.org> wrote:
> This is a long-standing oversight: HeapDumpPath does not recognise %p for pid expansion.
> The default filename uses a pid (e.g. java_pid1676937.hprof) but HeapDumpPath does not.
> It has always done a manual "root plus pid plus extension" on the default filename only, and
> should move to using Argument::copy_expand_pid() like we do with other such filenames.
>
>
> We also assumed the default filename is not a directory (which is very very likely, but doesn't have to be true).
This pull request has now been integrated.
Changeset: 7a7b9ed7
Author: Kevin Walls <kevinw at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/7a7b9ed7fe4a10bca155b0877c3e731f9d343b92
Stats: 71 lines in 2 files changed: 10 ins; 37 del; 24 mod
8353727: HeapDumpPath doesn't expand %p
Reviewed-by: stuefe, lmesnik
-------------
PR: https://git.openjdk.org/jdk/pull/24482
From iklam at openjdk.org Wed Apr 9 15:03:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Apr 2025 15:03:44 GMT
Subject: RFR: 8353597: Refactor handling VM options for AOT cache input and
output [v2]
In-Reply-To: <X8Hu2K8M2ATW-h1bLWrLMXSOrYgRdYGegSPjXlXwXZI=.7a96bcd1-dd94-4006-b79d-14fade32f732@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
<gyp83FTxXGoSL-ZpuJS-YZtW3Zm21LzkI5JB2znqFWo=.68435a6a-ba53-4a11-8f71-ae626518b9e6@github.com>
<RjLZX5oc4x77uuGSRtZ2jC5n_0G_Bcia3gVbCFsS6LY=.487eb5ab-a28c-4fcd-bd76-6fa993243122@github.com>
<hIM0L5pWqYODQAnc0TJvXZi7bjBGTlZx_RlT_nMrzUk=.36ee17a3-ef8f-4b83-a8ce-9d7e6013890a@github.com>
<X8Hu2K8M2ATW-h1bLWrLMXSOrYgRdYGegSPjXlXwXZI=.7a96bcd1-dd94-4006-b79d-14fade32f732@github.com>
Message-ID: <ugSq2CaCsyXhaPXgA-qh_dYmdhbxLrVE6We4gHyOIsw=.b7c92519-1600-4cfd-a141-856ecab02374@github.com>
On Thu, 3 Apr 2025 22:02:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:
>>> @iklam one annoying thing in current ergonomic setting for AOTCode flags in mainline is checking which phase we are executing. We agreed before that we should only save/load AOT code when `AOTClassLinking` is on because AOT code needs classes to be preloaded.
>>>
>>> I have to do next checks to enable AOTCode in `CDSConfig::check_vm_args_consistency()`:
>>>
>>> ```
>>> if (AOTClassLinking && is_using_archive() && !is_dumping_archive() && !FLAG_IS_DEFAULT(AOTCache)) {
>>> FLAG_SET_ERGO_IF_DEFAULT(LoadAOTCode, true);
>>> ...
>>> if (AOTClassLinking && is_dumping_final_static_archive()) {
>>> FLAG_SET_ERGO_IF_DEFAULT(StoreAOTCode, true);
>>> ```
>>>
>>> First, I am not sure these conditions are correct.
>>>
>>> Second, it would be nice to have simple checks instead: `is_dumping_aot_archive()` and `is_using_aot_archive()`.
>>>
>>> May be also consider it is error if both conditions are true (we don't support updating archive yet).
>>
>> There are a lot of dependencies between different AOT capabilities, and it's hard to control that using global variables. At the point of `CDSConfig::check_vm_args_consistency()`, we don't have complete knowledge whether the AOT cache exists, or whether the cache contains AOT code, or whether the GC compressed oops settings are compatible with the AOT code.
>>
>> In the handling of such "AOT capability flags", I have been using the following pattern:
>>
>> In `CDSConfig::check_vm_args_consistency()` we update the default values of the flags according to their dependencies on other flags. E.g., by specifying `-XX:AOTMode=create`, `AOTClassLinking` and `AOTInvokeDynamicLinking` are enabled by default.
>>
>>
>> if (!FLAG_IS_DEFAULT(AOTMode)) {
>> // Using any form of the new AOTMode switch enables enhanced optimizations.
>> FLAG_SET_ERGO_IF_DEFAULT(AOTClassLinking, true);
>> }
>>
>> if (AOTClassLinking) {
>> // If AOTClassLinking is specified, enable all AOT optimizations by default.
>> FLAG_SET_ERGO_IF_DEFAULT(AOTInvokeDynamicLinking, true);
>> } else {
>> // AOTInvokeDynamicLinking depends on AOTClassLinking.
>> FLAG_SET_ERGO(AOTInvokeDynamicLinking, false);
>> }
>>
>>
>> However, the values of these flags are just advisory. Even if a flag is enabled, the underlying capability may be disabled. For example, `AOTClassLinking` requires the ability of dumping heap objects, which is not available if ZGC is used.
>>
>> Because the dependencies are complex, it's difficult to resolve them statically and set a globa...
>
> Thank you @iklam for explanation. I can do final adjustment to `Store|LoadAOTCode` flags values in `StoreAOTCode::initialize()` which is called from `initialize_shared_spaces()`:
>
>
> MetaspaceShared::initialize_shared_spaces() {
> ...
> static_mapinfo->patch_heap_embedded_pointers();
> ArchiveHeapLoader::finish_initialization();
> Universe::load_archived_object_instances();
> + AOTCodeCache::initialize();
>
>
> The question: at this place are all CDS AOT flags are final (flags compatibility and cache presence are verified)?
>
> Note, `Store|LoadAOTCode` flags are diagnostic and disabled by default. I need to set them to `true` somewhere.
Thanks @vnkozlov @ashu-mehra @DanHeidinga @lmesnik for the review
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24401#issuecomment-2790037592
From iklam at openjdk.org Wed Apr 9 15:07:14 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 9 Apr 2025 15:07:14 GMT
Subject: Integrated: 8353597: Refactor handling VM options for AOT cache input
and output
In-Reply-To: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
References: <Rb-zXOfi578GAy_HP3H9c0g03OFvVeU9eMIYpy14mzs=.a1502a1e-f339-4395-869f-64df2fb5fc01@github.com>
Message-ID: <5DDGpghIYxMiMRk8aXwnHqcBgepkaDIZJT0gxtje8JI=.0aad39c1-5513-4638-99f2-8a96f447595c@github.com>
On Thu, 3 Apr 2025 04:00:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> Since [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483), VM options such as `-XX:AOTCache `are implemented as aliases of "classical" CDS options such as `-XX:SharedArchiveFile`.
>
> In anticipation of the [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022), we should refactor the code that deals with the AOT options. Specifically, as we expect the JVM to be able to load from an "input AOT cache" and write to an "output AOT cache", we should clearly identify the input and output caches in separate APIs:
>
>
> const char* CDSConfig::input_static_archive_path();
> const char* CDSConfig::input_dynamic_archive_path();
> const char* CDSConfig::output_archive_path();
>
>
> This PR also cleans up the code by:
> - renaming a few function to reflect what they actually do
> - moving more "config" management code into cdsConfig.cpp
>
> There's also a behavioral bug fix: before this PR, `-XX:AOTCache` was handled by the `ergo_init_classic_archive_paths()` function, which allows two files to be specified. E.g., `java -XX:AOTCache=static.jsa:dynamic.jsa`. That's because `-XX:AOTCache` was implemented as an alias of `-XX:SharedArchiveFile`, and the latter allows this usage.
>
> However, this behavior is not specified in JEP 483. Allowing two files in -XX:AOTCache will cause unnecessary complexity when we implement [JDK-8353598: Allow AOT cache to be used in training run](https://bugs.openjdk.org/browse/JDK-8353598). Therefore, I added new test cases to disallow the use of two files. This also means that we don't need to modify the already over-complicated `ergo_init_classic_archive_paths()` for the AOT use cases
This pull request has now been integrated.
Changeset: 567c6885
Author: Ioi Lam <iklam at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/567c6885a377e5641deef9cd3498f79c5346cd6a
Stats: 309 lines in 15 files changed: 161 ins; 55 del; 93 mod
8353597: Refactor handling VM options for AOT cache input and output
Reviewed-by: kvn, asmehra
-------------
PR: https://git.openjdk.org/jdk/pull/24401
From ihse at openjdk.org Wed Apr 9 15:09:58 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 9 Apr 2025 15:09:58 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
<cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>>
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>
> - Convert the merged master changes to UTF-8
> - Merge master and fix conflicts
> - Close streams when finished loading into props
> - Adjust CF test to read in with UTF-8 to fix failing test
> - Reconvert CS.properties to UTF-8
> - Revert all changes to CurrencySymbols.properties
> - Bug6204853 should not be converted
> - Copyright year for CompileProperties
> - Redo translation for CS.properties
> - Spot convert CurrencySymbols.properties
> - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
> 20: # Peter Smolik
> 21: Cp1250 WINDOWS-1250 0x00FF
> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
This does not seem to have been a correct conversion.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2035582242
From duke at openjdk.org Wed Apr 9 16:23:45 2025
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 9 Apr 2025 16:23:45 GMT
Subject: RFR: 8341491: Reserve and commit memory operations should be
protected by NMT lock
In-Reply-To: <xGjaPM672k6g0QRPLdD9XfRfeQoTffvR7-UWNFYtTK4=.a73f3818-0e4a-4d7a-86fc-2015c2b6913a@github.com>
References: <ahwOs7ROjN3fdcXC8RBzkpZukmdzkkAMt9kqvh_UacE=.fe030f01-1e41-488c-8238-983dc6f9c9f3@github.com>
<h4NKslnaVrulREkzTc7CuQh_0l5QTLA100GRkfhApEk=.e71e26d2-53bc-4960-93eb-ac4afc215e39@github.com>
<xGjaPM672k6g0QRPLdD9XfRfeQoTffvR7-UWNFYtTK4=.a73f3818-0e4a-4d7a-86fc-2015c2b6913a@github.com>
Message-ID: <g1_EMmqqHojus8nb5E99HzXHfw9BbEPbFigWcdq1rFg=.7701218b-596e-47b2-bf6b-fe8a5e05eba0@github.com>
On Tue, 1 Apr 2025 15:29:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:
>> 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);
>
>> 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
>
> Sounds like a good idea.
>
>>
>> * swapping the order of `NmtVirtualMemoryLocker` and release/uncommit
>
> I wonder if this should be done as new RFE after the change below. It might need a bit of investigation to make sure that the reasoning around this is correct.
>
>>
>> * Fail fatally if release/uncommit does not complete.
>
> I think this would be a good, separate RFE to be done before we try to swap the order.
>
>>
>>
>> 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);
>> ```
>
> My thinking is that after you done (2) above, then you will not need to expose the NMT lock to this level. The code would be:
>
> MemTracker::record_some_operation(addr, bytes); // Lock confined inside this
>
> pd_unmap_memory(addr, bytes);
>
>
> So, I would wait with this cleanup until we know more about (2).
Thank you @stefank for the feedback. I've applied your suggestions.
@tstuefe, when you have time, can you please have another look at this? Based on the discussion above, I've reverted the changes to the locking scope in favor of new comments explaining the asymmetrical locking and warning against patterns that lead to races. The new tests that are still relevant are kept.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24084#issuecomment-2790269355
From jiangli at openjdk.org Wed Apr 9 17:14:27 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 9 Apr 2025 17:14:27 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK [v3]
In-Reply-To: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
Message-ID: <cNJkU0viAiG6xTPx-jvOTwx2InyLLNgvmLqpp7R61KU=.b22ec49b-65d9-4f86-bfee-fdb367d38b13@github.com>
> Please review this PR that changes `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` shared library if running on static JDK, instead just returns "libinstrument.<ext>" directly. Both test case #1 and #2 in `LoadAgentDcmdTest.run()` run ok on static JDK with the change:
>
> Commands:
> Test case #1: `JVMTI.agent_load libinstrument.so agent.jar`
> Test case #2: `JVMTI.agent_load libinstrument.so "agent.jar=foo=bar"`
>
> Additional notes/considerations:
>
> 1. I notice [JDKToolFinder.getJDKTool()](https://github.com/openjdk/jdk/blob/80ff7b9c9406c7845ecb3bc40910e92ccdd23ff2/test/lib/jdk/test/lib/JDKToolFinder.java#L41) is used by the test to find the `jcmd` tool. `JDKToolFinder.getJDKTool()` looks for the requested tool in both `test.jdk` and `compile.jdk`. When running the jtreg test on static JDK, it's able to locate the `jcmd` from `compile.jdk` even though the static JDK binary (`test.jdk`) does not provide the tool. For tools used by jtreg tests at runtime, how about change to always do that?
>
> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
>
> JVMTI.agent_load [arguments]
> Loads JVMTI native agent.
> Impact: Low
> arguments:
> library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
> agent option: (Optional) Option string to pass the agent. (STRING, no default value)
>
> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
Address @AlanBateman's comment:
- Updated copyright header
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24497/files
- new: https://git.openjdk.org/jdk/pull/24497/files/3b4ef50c..a0d3f627
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24497&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24497&range=01-02
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24497.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24497/head:pull/24497
PR: https://git.openjdk.org/jdk/pull/24497
From jiangli at openjdk.org Wed Apr 9 17:16:31 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 9 Apr 2025 17:16:31 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK [v2]
In-Reply-To: <XCR0sEtqdmsW8-repel2IktA5p_dEBHO2WDCRUlRH4M=.0d6d66ec-c147-4398-bab1-175cf86a42da@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
<c63vQ_eEpIrCQsm_ATZrV1lg6EM0Cl6AXYXdeBTT9HQ=.67f7778b-14fb-4e77-95d4-f94ccedb876a@github.com>
<XCR0sEtqdmsW8-repel2IktA5p_dEBHO2WDCRUlRH4M=.0d6d66ec-c147-4398-bab1-175cf86a42da@github.com>
Message-ID: <GuSabqePA6wsc4CCDydi_YXRgJlscoHvJppw16vN_I0=.397939e2-48ac-4133-931d-4e33f9757c29@github.com>
On Wed, 9 Apr 2025 11:00:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:
> I assume you've bump the copyright header before integrating.
Updated, thanks!
@AlanBateman Please help re-approve the PR.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24497#issuecomment-2790427078
From alanb at openjdk.org Wed Apr 9 17:40:32 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 9 Apr 2025 17:40:32 GMT
Subject: RFR: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK [v3]
In-Reply-To: <cNJkU0viAiG6xTPx-jvOTwx2InyLLNgvmLqpp7R61KU=.b22ec49b-65d9-4f86-bfee-fdb367d38b13@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
<cNJkU0viAiG6xTPx-jvOTwx2InyLLNgvmLqpp7R61KU=.b22ec49b-65d9-4f86-bfee-fdb367d38b13@github.com>
Message-ID: <s9Z-vWllTWlqjKbiqxKP0CeH4VVRBSP2tqVQk45KMts=.75d1ab1a-d905-41a6-8d17-ba8921b88559@github.com>
On Wed, 9 Apr 2025 17:14:27 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:
>> Please review this PR that changes `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` shared library if running on static JDK, instead just returns "libinstrument.<ext>" directly. Both test case #1 and #2 in `LoadAgentDcmdTest.run()` run ok on static JDK with the change:
>>
>> Commands:
>> Test case #1: `JVMTI.agent_load libinstrument.so agent.jar`
>> Test case #2: `JVMTI.agent_load libinstrument.so "agent.jar=foo=bar"`
>>
>> Additional notes/considerations:
>>
>> 1. I notice [JDKToolFinder.getJDKTool()](https://github.com/openjdk/jdk/blob/80ff7b9c9406c7845ecb3bc40910e92ccdd23ff2/test/lib/jdk/test/lib/JDKToolFinder.java#L41) is used by the test to find the `jcmd` tool. `JDKToolFinder.getJDKTool()` looks for the requested tool in both `test.jdk` and `compile.jdk`. When running the jtreg test on static JDK, it's able to locate the `jcmd` from `compile.jdk` even though the static JDK binary (`test.jdk`) does not provide the tool. For tools used by jtreg tests at runtime, how about change to always do that?
>>
>> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
>>
>> JVMTI.agent_load [arguments]
>> Loads JVMTI native agent.
>> Impact: Low
>> arguments:
>> library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
>> agent option: (Optional) Option string to pass the agent. (STRING, no default value)
>>
>> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>
> Address @AlanBateman's comment:
> - Updated copyright header
Marked as reviewed by alanb (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24497#pullrequestreview-2754244716
From jiangli at openjdk.org Wed Apr 9 17:50:42 2025
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 9 Apr 2025 17:50:42 GMT
Subject: Integrated: 8353938:
hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static
JDK
In-Reply-To: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
References: <rYvOos8uWNYm0rklzeURt-pZ11v9NnMwsUIeYzpsHUo=.98862f13-5417-4965-b06a-8256f6d56aa7@github.com>
Message-ID: <RtWIL7oBOAtWBt0DmEVW2xjcSEHMjJxMWDtguMoNdFg=.160b9725-4915-4acb-9124-e71179adf31d@github.com>
On Tue, 8 Apr 2025 02:25:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:
> Please review this PR that changes `LoadAgentDcmdTest.getLibInstrumentPath()` to not locate `libinstrument` shared library if running on static JDK, instead just returns "libinstrument.<ext>" directly. Both test case #1 and #2 in `LoadAgentDcmdTest.run()` run ok on static JDK with the change:
>
> Commands:
> Test case #1: `JVMTI.agent_load libinstrument.so agent.jar`
> Test case #2: `JVMTI.agent_load libinstrument.so "agent.jar=foo=bar"`
>
> Additional notes/considerations:
>
> 1. I notice [JDKToolFinder.getJDKTool()](https://github.com/openjdk/jdk/blob/80ff7b9c9406c7845ecb3bc40910e92ccdd23ff2/test/lib/jdk/test/lib/JDKToolFinder.java#L41) is used by the test to find the `jcmd` tool. `JDKToolFinder.getJDKTool()` looks for the requested tool in both `test.jdk` and `compile.jdk`. When running the jtreg test on static JDK, it's able to locate the `jcmd` from `compile.jdk` even though the static JDK binary (`test.jdk`) does not provide the tool. For tools used by jtreg tests at runtime, how about change to always do that?
>
> 2. From https://docs.oracle.com/en/java/javase/21/docs/specs/man/jcmd.html:
>
> JVMTI.agent_load [arguments]
> Loads JVMTI native agent.
> Impact: Low
> arguments:
> library path: Absolute path of the JVMTI agent to load. (STRING, no default value)
> agent option: (Optional) Option string to pass the agent. (STRING, no default value)
>
> The command spec requires the absolute path of the JVMTI agent for the `library path` argument. On static JDK, if the agent library is built-in (statically linked), passing the shared library name works and allows the VM to find the built-in agent. There would be no need to specify the absolute path. Please see ?https://bugs.openjdk.org/browse/JDK-8353938?focusedId=14767737&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14767737 for more details.
This pull request has now been integrated.
Changeset: faacbd96
Author: Jiangli Zhou <jiangli at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/faacbd96a3dc1116f3af590439585844ff8048a1
Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
8353938: hotspot/jtreg/serviceability/dcmd/jvmti/LoadAgentDcmdTest.java fails on static JDK
Reviewed-by: alanb
-------------
PR: https://git.openjdk.org/jdk/pull/24497
From coleenp at openjdk.org Wed Apr 9 19:24:25 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 9 Apr 2025 19:24:25 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <a567SZOzU9TbLalOD3U2Jg4GjrVOnkIsOOa-xft2rYg=.c184bae3-2d73-4b24-86f4-4b012e441c64@github.com>
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
So this is another case where you have to ignore JVMTI event like in VTMS transitions? It looks like a good way to fix this in general.
-------------
Marked as reviewed by coleenp (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24539#pullrequestreview-2754548627
From lmesnik at openjdk.org Wed Apr 9 19:41:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 9 Apr 2025 19:41:28 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <yevLa0Onzxv8WyvfkRexYg5jI1WUKU2y6EZYzrehxog=.75791909-40d3-4587-841f-a70a949d82c2@github.com>
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
Looks good.
-------------
Marked as reviewed by lmesnik (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24539#pullrequestreview-2754601842
From sgehwolf at openjdk.org Wed Apr 9 19:53:36 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 9 Apr 2025 19:53:36 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
[v17]
In-Reply-To: <ftsw92lx0y4ZTI_XZz1mgqEEKjNVB-L1G44AtJXvQM8=.cef4eac5-158a-4229-8ae5-6feae46e9f86@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
<ftsw92lx0y4ZTI_XZz1mgqEEKjNVB-L1G44AtJXvQM8=.cef4eac5-158a-4229-8ae5-6feae46e9f86@github.com>
Message-ID: <8J81yHp6pB8F9BtQfyXPziqyCCrQP5NSasjiu5HzGWg=.db593ac0-7259-4cda-832d-1e872114db44@github.com>
On Tue, 1 Apr 2025 14:59:37 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 44 commits:
>
> - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
> - JDK-8350103
> - 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
> - ... and 34 more: https://git.openjdk.org/jdk/compare/6801eb87...32960cd6
Keep open, please.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2790835637
From amenkov at openjdk.org Wed Apr 9 20:18:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 9 Apr 2025 20:18:33 GMT
Subject: RFR: 8353485: Jcms should allow to specify streaming_output mode
In-Reply-To: <R9D0dMqa9dWWfp0hrz2DV5J_SsPhEb18gPOxGyo_cws=.973c17a3-ac58-427a-af9f-746b83dc5e10@github.com>
References: <R9D0dMqa9dWWfp0hrz2DV5J_SsPhEb18gPOxGyo_cws=.973c17a3-ac58-427a-af9f-746b83dc5e10@github.com>
Message-ID: <al2y4Ej4tDh5aXh5xTzth9pMnkIgu2PtwK0xMMCftkg=.ab5c9af7-c998-44f3-81a6-b61f3af2cb1d@github.com>
On Mon, 7 Apr 2025 17:59:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
> The fix adds `--streaming_output` jcmd option to manage attach command streaming output.
>
> Testing: tier1..tier4,hs-tier5-svc
Streaming output for attach client can be set by "jdk.attach.allowStreamingOutput" property, passing the value by using launcher VM args ("-J"). Closing the issue
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24494#issuecomment-2790896487
From amenkov at openjdk.org Wed Apr 9 20:18:33 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 9 Apr 2025 20:18:33 GMT
Subject: Withdrawn: 8353485: Jcms should allow to specify streaming_output mode
In-Reply-To: <R9D0dMqa9dWWfp0hrz2DV5J_SsPhEb18gPOxGyo_cws=.973c17a3-ac58-427a-af9f-746b83dc5e10@github.com>
References: <R9D0dMqa9dWWfp0hrz2DV5J_SsPhEb18gPOxGyo_cws=.973c17a3-ac58-427a-af9f-746b83dc5e10@github.com>
Message-ID: <_7PY4MvTI4Dn20hFlIvafw7ioRzjYOIcHpeWluuew2I=.220333cd-f3ea-4273-a3b3-6329cf47acbc@github.com>
On Mon, 7 Apr 2025 17:59:24 GMT, Alex Menkov <amenkov at openjdk.org> wrote:
> The fix adds `--streaming_output` jcmd option to manage attach command streaming output.
>
> Testing: tier1..tier4,hs-tier5-svc
This pull request has been closed without being integrated.
-------------
PR: https://git.openjdk.org/jdk/pull/24494
From cjplummer at openjdk.org Wed Apr 9 20:28:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Apr 2025 20:28:33 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
<cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
<XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>
Message-ID: <A0q4f4ReyrArEbDyLRPY2acAcn2Afzc7wi3i-7WVp4k=.0c1c0a52-148e-4166-bcaa-670905ea59f4@github.com>
On Wed, 9 Apr 2025 14:17:25 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> Making hotspot `-Os` would certainly never make any sense, for example.)
When the minimalVM was first created, there was a quite of bit of benchmarking done to decide which hotspot files to build with -Os and which to build with -O3. I'm not sure if this split survived the new build system, but for those wanting a truly minimal footprint with reasonable performance sacrifices, it still makes sense to build all or most of hotspot with -Os.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2790923666
From cjplummer at openjdk.org Wed Apr 9 20:37:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Apr 2025 20:37:33 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
<WSsXLUSlfe-ouwBWIacUatrkGd6Vr_6I-diw7l29058=.4f46c44a-2c78-4b0e-9122-a40ca249fe8a@github.com>
Message-ID: <XkGbUGRdFEN2yW2Gl5KVahM0oWX00JkyVuElZ6OvIzs=.f3e3aa53-b7b4-4a1e-9349-6a8012824ffe@github.com>
On Wed, 9 Apr 2025 10:41:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:
> Wait, `LOW` is `-O2`? ? I thought it was like no optimization at all. I'm sooo confused with these levels. So maybe going from `LOW` to `SIZE` will actually lose more optimization than I thought. _sigh_
-Os is the same as -O2 minus some optimizations that increase footprint.
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
-O3 mostly adds more serious footprint increasing optimizations like loop unrolling. I've seen a number of warnings that suggest in some cases the larger code can reduce performance, so you may be best off with -O2 or -Os for best performance.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2790938638
From cjplummer at openjdk.org Wed Apr 9 20:45:32 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Apr 2025 20:45:32 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <PE8v2v5bpjPtXYHlMe6-WdqDvKoD_X5dVGS0XwINGBs=.8abc5dad-99ae-4102-9f9d-333e8480c6d7@github.com>
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
src/hotspot/share/prims/jvmtiEnvBase.cpp line 867:
> 865: // This call collects the strong and weak groups
> 866: JavaThread* THREAD = current_thread;
> 867: JvmtiJavaUpcallMark jjum(current_thread);
Add comment like you did above for the JvmtiEnv::InterruptThread case.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24539#discussion_r2036109049
From cjplummer at openjdk.org Wed Apr 9 20:52:48 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Apr 2025 20:52:48 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <QM4HMG6VpwtVvI055vlp8qiGi1AQCY7scs2EbV1QpvM=.d07a8a34-acab-4c76-8f11-f131d20e3543@github.com>
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
src/hotspot/share/prims/jvmtiExport.cpp line 1419:
> 1417: // ClassPrepare events are important for JDWP agent but not expected during such upcalls.
> 1418: // Catch if this invariant is not broken.
> 1419: assert(!thread->is_in_java_upcall(), "unexpected ClassPrepare event during JVMTI upcall");
I think we should do this for ClassLoad also.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24539#discussion_r2036122548
From jlu at openjdk.org Wed Apr 9 21:28:41 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 9 Apr 2025 21:28:41 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v6]
In-Reply-To: <_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
<cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
<_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
Message-ID: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
On Wed, 9 Apr 2025 15:06:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>>
>> - Convert the merged master changes to UTF-8
>> - Merge master and fix conflicts
>> - Close streams when finished loading into props
>> - Adjust CF test to read in with UTF-8 to fix failing test
>> - Reconvert CS.properties to UTF-8
>> - Revert all changes to CurrencySymbols.properties
>> - Bug6204853 should not be converted
>> - Copyright year for CompileProperties
>> - Redo translation for CS.properties
>> - Spot convert CurrencySymbols.properties
>> - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a
>
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
>
>> 20: # Peter Smolik
>> 21: Cp1250 WINDOWS-1250 0x00FF
>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
>
> This does not seem to have been a correct conversion.
Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036165417
From sspitsyn at openjdk.org Wed Apr 9 22:37:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Apr 2025 22:37:27 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <PE8v2v5bpjPtXYHlMe6-WdqDvKoD_X5dVGS0XwINGBs=.8abc5dad-99ae-4102-9f9d-333e8480c6d7@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<PE8v2v5bpjPtXYHlMe6-WdqDvKoD_X5dVGS0XwINGBs=.8abc5dad-99ae-4102-9f9d-333e8480c6d7@github.com>
Message-ID: <qjmevnJeB_xURAfjJZPwksuj9mUIWjFNYpPpFHGFGGw=.754967f8-346c-4816-9ded-62aa629f74bc@github.com>
On Wed, 9 Apr 2025 20:38:08 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 867:
>
>> 865: // This call collects the strong and weak groups
>> 866: JavaThread* THREAD = current_thread;
>> 867: JvmtiJavaUpcallMark jjum(current_thread);
>
> Add comment like you did above for the JvmtiEnv::InterruptThread case.
Okay, thanks! Added now.
> src/hotspot/share/prims/jvmtiExport.cpp line 1419:
>
>> 1417: // ClassPrepare events are important for JDWP agent but not expected during such upcalls.
>> 1418: // Catch if this invariant is not broken.
>> 1419: assert(!thread->is_in_java_upcall(), "unexpected ClassPrepare event during JVMTI upcall");
>
> I think we should do this for ClassLoad also.
Okay, thanks! Updated now.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24539#discussion_r2036227345
PR Review Comment: https://git.openjdk.org/jdk/pull/24539#discussion_r2036227287
From sspitsyn at openjdk.org Wed Apr 9 22:41:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Apr 2025 22:41:05 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v2]
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <f__Ks1L_5uvqlmTyh-K2Eui2jv4BqVXqq4DKj1j9Jxs=.c3b24061-e762-4682-b9b1-d84147812b1b@github.com>
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
review: 1) added an assert for ClassLoad events same as for ClassPrepare; 2) added one minor comment
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24539/files
- new: https://git.openjdk.org/jdk/pull/24539/files/82e99fae..342e8a78
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24539&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24539&range=00-01
Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24539.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24539/head:pull/24539
PR: https://git.openjdk.org/jdk/pull/24539
From sspitsyn at openjdk.org Wed Apr 9 22:41:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Apr 2025 22:41:05 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <-h8tEhjnCVtV4HP9CvhZZEnYUvyJyehZ8aZV44m1bD4=.9db1813e-225e-4352-b09f-2042fdf8fbdf@github.com>
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
Coleen and Leonid, thank you for review!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24539#issuecomment-2791132661
From sspitsyn at openjdk.org Wed Apr 9 22:47:24 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 9 Apr 2025 22:47:24 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v2]
In-Reply-To: <a567SZOzU9TbLalOD3U2Jg4GjrVOnkIsOOa-xft2rYg=.c184bae3-2d73-4b24-86f4-4b012e441c64@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<a567SZOzU9TbLalOD3U2Jg4GjrVOnkIsOOa-xft2rYg=.c184bae3-2d73-4b24-86f4-4b012e441c64@github.com>
Message-ID: <jpWTUfOGynX9PBnnEgK7b-3CbyDSwo9pmPywPjtkyJU=.68f52af6-c70d-470c-a59e-c29b97b1b648@github.com>
On Wed, 9 Apr 2025 19:21:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> So this is another case where you have to ignore JVMTI event like in VTMS transitions? It looks like a good way to fix this in general.
Yes. This is a long standing issue which is good to fix now.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24539#issuecomment-2791140522
From cjplummer at openjdk.org Wed Apr 9 23:29:33 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 9 Apr 2025 23:29:33 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v2]
In-Reply-To: <qjmevnJeB_xURAfjJZPwksuj9mUIWjFNYpPpFHGFGGw=.754967f8-346c-4816-9ded-62aa629f74bc@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<PE8v2v5bpjPtXYHlMe6-WdqDvKoD_X5dVGS0XwINGBs=.8abc5dad-99ae-4102-9f9d-333e8480c6d7@github.com>
<qjmevnJeB_xURAfjJZPwksuj9mUIWjFNYpPpFHGFGGw=.754967f8-346c-4816-9ded-62aa629f74bc@github.com>
Message-ID: <YXtMJ5PAZ4ixQEjCJCaMRQsDjgAUUPizGMjTIippr5A=.09436c3f-e794-4224-9673-95ba58c37587@github.com>
On Wed, 9 Apr 2025 22:34:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> src/hotspot/share/prims/jvmtiExport.cpp line 1419:
>>
>>> 1417: // ClassPrepare events are important for JDWP agent but not expected during such upcalls.
>>> 1418: // Catch if this invariant is not broken.
>>> 1419: assert(!thread->is_in_java_upcall(), "unexpected ClassPrepare event during JVMTI upcall");
>>
>> I think we should do this for ClassLoad also.
>
> Okay, thanks! Updated now.
> Catch if this invariant is not broken
I think you mean "Catch if this invariant is broken"
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24539#discussion_r2036269670
From fyang at openjdk.org Thu Apr 10 02:16:36 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 10 Apr 2025 02:16:36 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: <5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
<5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
Message-ID: <A4_hpBzPbkzr8MAgjfejK3SvuyQl3nPUZ6z0qQ2E8Y4=.641a801a-39a7-4575-9f2a-ab43b1ebbddd@github.com>
On Mon, 31 Mar 2025 10:45:54 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 explicit or implicit (sysroot).
>> E.g. "ptrace(PTRACE_ATTACH, ..) failed for 405157: Function not implemented'" for SA tests.
>>
>> 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
> qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
>
> `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
>
> Tests are only excluded if we know it's qemu-user.
> qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
>
> `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
>
> Tests are only excluded if we know it's qemu-user.
Sorry for not being clear enough. Yes, that's how it works with qemu-user for riscv.
Just wondering if it makes sense to extend this to other CPU platforms. There are two cases.
- Case 1: The tests are excluded as expected if we parses "qemu" in cpuinfo with qemu-user for another CPU, which is simiar with qemu-user for riscv. But I am not sure if there is one for now.
- Case 2: The tests are NOT excluded as there's no "qemu" in cpuinfo with qemu-user for another CPU. Then we still got test failures as before. But we are not causing any more regressions. I may consider that as a qemu-user issue for this CPU. And it could be fixed on the qemu-user side if it really helps people.
Maybe I am demanding too much about qemu-user. What do you think?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2791376594
From sspitsyn at openjdk.org Thu Apr 10 05:50:23 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 05:50:23 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v3]
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
review: minor tweak in two similar comments
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24539/files
- new: https://git.openjdk.org/jdk/pull/24539/files/342e8a78..f0b70372
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24539&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24539&range=01-02
Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/24539.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24539/head:pull/24539
PR: https://git.openjdk.org/jdk/pull/24539
From sspitsyn at openjdk.org Thu Apr 10 05:50:23 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 05:50:23 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v3]
In-Reply-To: <YXtMJ5PAZ4ixQEjCJCaMRQsDjgAUUPizGMjTIippr5A=.09436c3f-e794-4224-9673-95ba58c37587@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<PE8v2v5bpjPtXYHlMe6-WdqDvKoD_X5dVGS0XwINGBs=.8abc5dad-99ae-4102-9f9d-333e8480c6d7@github.com>
<qjmevnJeB_xURAfjJZPwksuj9mUIWjFNYpPpFHGFGGw=.754967f8-346c-4816-9ded-62aa629f74bc@github.com>
<YXtMJ5PAZ4ixQEjCJCaMRQsDjgAUUPizGMjTIippr5A=.09436c3f-e794-4224-9673-95ba58c37587@github.com>
Message-ID: <BNQ2ucBs07MPr54FCXEztT8qPqYuY7kxCBSidXCQyMs=.61ec5dfc-5e76-49b1-a18c-1958a2ba305d@github.com>
On Wed, 9 Apr 2025 23:27:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Okay, thanks! Updated now.
>
>> Catch if this invariant is not broken
> I think you mean "Catch if this invariant is broken"
Okay, thanks! Fixed this comment now in both places.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24539#discussion_r2036550047
From aboldtch at openjdk.org Thu Apr 10 06:18:38 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 10 Apr 2025 06:18:38 GMT
Subject: RFR: 8350441: ZGC: Overhaul Page Allocation
In-Reply-To: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
References: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
Message-ID: <EXye6LAIgz3eRzshOs_546qe0hAwOkLbzmdqZORcH5o=.b0cf3055-583f-4a9b-8d26-45aecf487a4f@github.com>
On Wed, 9 Apr 2025 13:37:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
>
> # Background
>
> This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
>
> In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
>
> # Mapped Cache
>
> The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
>
> The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
>
> # Fragmentation
>
> Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
>
> ## Virtual Memory Shuffling
>
> In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with virtual memory. When harvesting memory, whic...
src/hotspot/share/gc/z/zVirtualMemoryManager.hpp line 89:
> 87: ZVirtualMemoryManager(size_t max_capacity);
> 88:
> 89: void initialize_partitions(ZVirtualMemoryReserver* reserver, size_t reserved);
Suggestion:
void initialize_partitions(ZVirtualMemoryReserver* reserver, size_t size_for_partitions);
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24547#discussion_r2036582513
From sspitsyn at openjdk.org Thu Apr 10 06:41:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 06:41:42 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
timed out [v4]
In-Reply-To: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
Message-ID: <iKEVgTAFOuWtJkVRfEov5MdBz8FPClN4Ny1Byl25jQQ=.4d2d3e1c-97fd-4a6b-a54f-67c73d5b3c77@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:
review: added general comment about sync between suspend_thread and resume_thread
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24269/files
- new: https://git.openjdk.org/jdk/pull/24269/files/4a92986a..df99ba15
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24269&range=02-03
Stats: 19 lines in 3 files changed: 16 ins; 0 del; 3 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 Apr 10 06:41:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 06:41:42 GMT
Subject: RFR: 8316682: serviceability/jvmti/vthread/SelfSuspendDisablerTest
timed out [v2]
In-Reply-To: <XlHX9roympjELefi8aLirpIsEggB_qx5chzEeB4xgVY=.8d343e49-e2b0-4971-8cf4-964b60c41a32@github.com>
References: <JfrC7udzGmX3SMG1_QGGjorEojLPlUF8Imyg36OwRpA=.392a713d-d601-425e-8135-e1017dac02a4@github.com>
<zDha5jkc0ajVnhq1bXoOPKQ4M9RXjdDMDfJcq4_ZPtI=.619e6269-1c58-4ab5-9570-9ab397df5922@github.com>
<iAYNgKws-37b1b8PHBZhN4tyaXgKgvm9AuA5WNQvPWI=.9c7949f1-9837-4a1e-8055-200718aefdff@github.com>
<XlHX9roympjELefi8aLirpIsEggB_qx5chzEeB4xgVY=.8d343e49-e2b0-4971-8cf4-964b60c41a32@github.com>
Message-ID: <wAk_xCdJHwAgpCdJsYCY_LE2NEy1GYOdD1v6UKBRqhI=.888e8d11-e512-4ffd-bd0a-8bb5e6e4d636@github.com>
On Fri, 4 Apr 2025 06:21:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1759:
>>
>>> 1757: Handle thread_h(current, thread_oop);
>>> 1758: bool is_virtual = java_lang_VirtualThread::is_instance(thread_h());
>>> 1759: bool is_thread_carrying = is_thread_carrying_vthread(java_thread, thread_h());
>>
>> I think that somewhere in this place should be an explanation of suspend<->resume synchronization. As I understand the hadshake can't be executed and clear suspend state while suspend_thread is done for the same thread. How it is guaranteed that suspend_thread flag cann't be updated?
>> It is not obvious and also put some restrictions on the suspend_thread implementation to keep this behaviour.
>
> Thank you for reviewing and this suggestion.
> Yes, you are right. I'll try to find a good place to add such a comment.
I've added a comment you requested. Please, let me know if it is enough or there are some comments/suggestions.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2036612988
From rehn at openjdk.org Thu Apr 10 07:08:39 2025
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 10 Apr 2025 07:08:39 GMT
Subject: RFR: 8352730: RISC-V: Disable tests in qemu-user [v3]
In-Reply-To: <A4_hpBzPbkzr8MAgjfejK3SvuyQl3nPUZ6z0qQ2E8Y4=.641a801a-39a7-4575-9f2a-ab43b1ebbddd@github.com>
References: <fJaBpSFj4mhZZvS2kge0HEdaV5PR0fPpIBBAd3Ct0ZQ=.6b689707-32db-4df4-b181-911e5367fe8d@github.com>
<5sujqD7L_cmLUyDwYb4PhgOlEeiFwlkAV7RJoVMFTrM=.223437cd-bbb2-4ef3-a6fe-b13ce402e14b@github.com>
<A4_hpBzPbkzr8MAgjfejK3SvuyQl3nPUZ6z0qQ2E8Y4=.641a801a-39a7-4575-9f2a-ab43b1ebbddd@github.com>
Message-ID: <D8Y_bA_V0IZ2tUVUnWIhGn_BmB0osZTKwtQjC3OYpYA=.be0f8e47-0d02-4155-a5d8-dc949dd25276@github.com>
On Thu, 10 Apr 2025 02:13:46 GMT, Fei Yang <fyang at openjdk.org> wrote:
> > qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
> > `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
> > Tests are only excluded if we know it's qemu-user.
>
> > qemu-user, "uarch: qemu" in cpuinfo: `[0.084s][info ][os,cpu] CPU: total 28 (initial active 28) qemu rv64 rvi rvm rva rvf rvd rvc rvv zba zbb zbs zfh zfhmin zvbc zvfh zicond` Hence we know this is qemu-user (only qemu-user sets uarch to qemu on riscv).
> > `/proc/cpuinfo` do not contain uarch: [0.053s][info ][os,cpu] CPU: total 8 (initial active 8) rv64 rvi rvm rva rvf rvd rvc zba zbb zbs zfh zfhmin zvfh zicond We have no clue if this is emulated or on real hardware, tests will be executed.
> > Tests are only excluded if we know it's qemu-user.
>
> Sorry for not being clear enough. Yes, that's how it works with qemu-user for riscv. Just wondering if it makes sense to extend this to other CPU platforms. There are two cases.
>
> * Case 1: The tests are excluded as expected if we parses "qemu" in cpuinfo with qemu-user for another CPU, which is simiar with qemu-user for riscv. But I am not sure if there is one for now.
> * Case 2: The tests are NOT excluded as there's no "qemu" in cpuinfo with qemu-user for another CPU. Then we still got test failures as before. But we are not causing any more regressions. I may consider that as a qemu-user issue for this CPU. And it could be fixed on the qemu-user side if it really helps people.
>
> Maybe I am demanding too much about qemu-user. What do you think?
There is additional step:
The linux cpu vm_version also need to parse the /proc/cpuinfo and add that to the JVM cpu string.
Right now only rv64 and aarch64 opens that file AFIACT.
And in qemu-user the only JVM supported platforms adding qemu to cpuinfo is s390 and rv64.
I'll ask qemu folks and get a feel for if I can upstream some changes addressing this.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24229#issuecomment-2791764329
From mbaesken at openjdk.org Thu Apr 10 07:15:30 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 10 Apr 2025 07:15:30 GMT
Subject: RFR: 8349638: Build libjdwp with SIZE optimization
In-Reply-To: <A0q4f4ReyrArEbDyLRPY2acAcn2Afzc7wi3i-7WVp4k=.0c1c0a52-148e-4166-bcaa-670905ea59f4@github.com>
References: <y3HD3XitlnyoJL9BA4SNBHVXrFeR34Sq4rkgAV1j0Ag=.346b1eb1-b31b-4650-9238-7a3c40d17435@github.com>
<cOQGiBqxmkyzgfiJhOTyqZZjk6_NvFCal7p8u9i-SqQ=.e8874514-e4e5-4aa4-a96b-0abd900325d6@github.com>
<XRY-Q8YeYdzZMjijKxgprNS7zU8kOsV1GjkYnNEdt1M=.756fa25f-34ce-4e4c-9bf4-41e52d39446f@github.com>
<A0q4f4ReyrArEbDyLRPY2acAcn2Afzc7wi3i-7WVp4k=.0c1c0a52-148e-4166-bcaa-670905ea59f4@github.com>
Message-ID: <oQOhk3uyl29N9qzgwZW2nsleDpLJ6HcXF-24L0mq0Ho=.802015bd-37ed-4335-a0a4-2e6a81632b01@github.com>
On Wed, 9 Apr 2025 20:26:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> > Making hotspot `-Os` would certainly never make any sense, for example.)
>
> When the minimalVM was first created, there was a quite of bit of benchmarking done to decide which hotspot files to build with -Os and which to build with -O3. I'm not sure if this split survived the new build system, but for those wanting a truly minimal footprint with reasonable performance sacrifices, it still makes sense to build all or most of hotspot with -Os.
The list to decide which hotspot files to build with -Os and which to build with -O3 (OPT_SPEED_SRC ) is still present , see https://github.com/openjdk/jdk/blob/master/make/hotspot/lib/JvmFeatures.gmk#L197 . Probably the list is a bit outdated.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2791779866
From ihse at openjdk.org Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v6]
In-Reply-To: <f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
<cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
<_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
<f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
Message-ID: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
On Wed, 9 Apr 2025 21:26:15 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties line 22:
>>
>>> 20: # Peter Smolik
>>> 21: Cp1250 WINDOWS-1250 0x00FF
>>> 22: # Patch attributed to havardw at underdusken.no (H?vard Wigtil)
>>
>> This does not seem to have been a correct conversion.
>
> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
>
> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036695622
From ihse at openjdk.org Thu Apr 10 07:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 07:34:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v6]
In-Reply-To: <tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
<cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
<_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
<f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
<tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
Message-ID: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
On Thu, 10 Apr 2025 07:31:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>> Right, that `?` looks to have been incorrectly converted during the ISO-8859-1 to UTF-8 conversion. (I can't find the script used for conversion as this change is from some time ago.)
>>
>> Since the change occurs in a comment (thankfully), it should be harmless and the next upstream update of this file would overwrite this incorrect change. However, this file does not seem to be updated that often, so I can also file an issue to correct this if you would prefer that.
>
> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036696723
From dholmes at openjdk.org Thu Apr 10 07:37:26 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Apr 2025 07:37:26 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v3]
In-Reply-To: <ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
Message-ID: <PJJgPStPmzVwjmovNf3d8JSqz2qesMG5EbFhGjhpCss=.6533bb07-2afb-49dd-9317-7ffbbf47f87b@github.com>
On Thu, 10 Apr 2025 05:50:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> review: minor tweak in two similar comments
This looks reasonable to me. Thanks.
-------------
Marked as reviewed by dholmes (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24539#pullrequestreview-2755643289
From eirbjo at openjdk.org Thu Apr 10 08:10:42 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:10:42 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v6]
In-Reply-To: <Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
<cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
<_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
<f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
<tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
<Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
Message-ID: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
On Thu, 10 Apr 2025 07:32:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>> You don't have to do that, I'm working on an omnibus UTF-8 fixing PR right now, where I will include a fix for this as well.
>
> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
Some observations:
1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?
2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.
3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`
4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:
byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
String decoded = new String(origBytes, StandardCharsets.UTF_8);
byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
String hex = HexFormat.of().formatHex(encoded);
assertEquals("efbfbd", hex);
```
Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036767319
From ihse at openjdk.org Thu Apr 10 08:38:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:38:38 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v6]
In-Reply-To: <6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
<cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
<_YOUyzMbSEXFduCKVgyis37kwTlGSjBbP8VlFu3xQpU=.9b668e2a-8f91-476d-8914-13dc33a0b9e5@github.com>
<f565K9bPPbDC3a6M34NDH-DLKzxunYzBaSTkcOAF8bM=.0d00299f-48f7-43ef-8b70-f037bd1441c1@github.com>
<tfpN5b1ld7DNt2HZDgxqWONwyUdyV9GZ27pW5Wjj5mc=.9bcea0db-9d33-40d3-89b3-f8d329da29e7@github.com>
<Ivm7XuioTIWOn0303Mm7LUqVPTRhzYRMd8IL8l7EZzA=.463fee71-99a5-420d-827b-eefe7f819877@github.com>
<6c6DqyCqyPonBZgUU8BpYJR3JQvMXjWm9ulq4SN25Do=.77775825-716d-4908-ae24-c4cf1ead78a5@github.com>
Message-ID: <qG3Fpev16BBWYvs2zSE5CeqmTcfRF4h_l-PAM3PVHns=.4a1e25de-c3e2-4876-a8e5-c3f32cfef4c1@github.com>
On Thu, 10 Apr 2025 08:08:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:
>> If anything, I might be a bit worried that there are more incorrect conversions stemming from this PR, that my automated tools and manual scanning has not revealed.
>
> Some observations:
>
> 1: This PR seems to have been abondoned, so perhaps this discussion belongs in #15694 ?
>
> 2: The `?` (Unicode 'Latin small letter a with ring above' U+00E5) was correctly encoded as 0xEF in ISO-8859-1 previous to this change.
>
> 3: The conversion changed this `0xEF` to the three-byte sequence `ef bf bd`
>
> 4: This is as-if the file was incorrctly decoded using UTF-8, then encoded using UTF-8:
>
>
> byte[] origBytes = "?".getBytes(StandardCharsets.ISO_8859_1);
> String decoded = new String(origBytes, StandardCharsets.UTF_8);
> byte[] encoded = decoded.getBytes(StandardCharsets.UTF_8);
> String hex = HexFormat.of().formatHex(encoded);
> assertEquals("efbfbd", hex);
> ```
>
> Like @magicus I'm worried that similar incorrect decoding could have been introduced by the same script in other files.
> This PR seems to have been abondoned, so perhaps this discussion belongs in https://github.com/openjdk/jdk/pull/15694 ?
Oh, I didn't notice this was supplanted by another PR. It might be better to continue there, yes. Even if closed PRs seldom are the best places to conduct discussions, I think it might be a good idea to scrutinize all files modified by this script.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/12726#discussion_r2036820765
From ihse at openjdk.org Thu Apr 10 08:41:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 08:41:45 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
<wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <yO1q1NVjOInbzcWCkJra3sYGkfv3OBhg__dKO0w--s0=.d7a4b185-6ed1-4ae6-bdfe-01b3204da46a@github.com>
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>>
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>>
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>>
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>>
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>
> Replace InputStreamReader with BufferedReader
Continuing the discussion that was started at a predecessor to this PR, https://github.com/openjdk/jdk/pull/12726#discussion_r2035582242. At least one incorrect conversion has been found in this PR. It might be worthwhile to double- and triple-check all the other conversions as well.
As part of https://bugs.openjdk.org/browse/JDK-8301971 I am trying various ways of detecting files without UTF-8 encoding, but it is still a bit of hit and miss, since there are no surefire way of telling which encoding a file has, only heuristics. So finding and following up potential sources of error is important.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791991649
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2791997157
From eirbjo at openjdk.org Thu Apr 10 08:48:37 2025
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 10 Apr 2025 08:48:37 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
<wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>>
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>>
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>>
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>>
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>
> Replace InputStreamReader with BufferedReader
FWIW, I checked out the revision of the commit previous to this change and found the following:
% git checkout b55e418a077791b39992042411cde97f68dc39fe^
% find src -name "*.properties" | xargs file | grep -v ASCII
src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties:
ISO-8859 text
src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
Unicode text, UTF-8 text, with very long lines (322)
Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792014164
From jsikstro at openjdk.org Thu Apr 10 09:20:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 10 Apr 2025 09:20:58 GMT
Subject: RFR: 8350441: ZGC: Overhaul Page Allocation [v2]
In-Reply-To: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
References: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
Message-ID: <lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
>> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
>
> # Background
>
> This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
>
> In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
>
> # Mapped Cache
>
> The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
>
> The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
>
> # Fragmentation
>
> Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
>
> ## Virtual Memory Shuffling
>
> In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with virtual memory. When harvesting memory, whic...
Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
Update src/hotspot/share/gc/z/zVirtualMemoryManager.hpp
Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24547/files
- new: https://git.openjdk.org/jdk/pull/24547/files/5f9caa7a..ea2b5f97
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24547&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24547&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24547.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24547/head:pull/24547
PR: https://git.openjdk.org/jdk/pull/24547
From aboldtch at openjdk.org Thu Apr 10 09:20:58 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 10 Apr 2025 09:20:58 GMT
Subject: RFR: 8350441: ZGC: Overhaul Page Allocation [v2]
In-Reply-To: <lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
References: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
<lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
Message-ID: <SgYIIFHv980JfVH0_1n1bgKqmsLP8RiZuFWET-Hzh0w=.db670dcc-2cc5-4059-9930-6403e16ca812@github.com>
On Thu, 10 Apr 2025 09:16:56 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>>> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
>>
>> # Background
>>
>> This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
>>
>> In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
>>
>> # Mapped Cache
>>
>> The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
>>
>> The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
>>
>> # Fragmentation
>>
>> Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
>>
>> ## Virtual Memory Shuffling
>>
>> In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with vir...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Update src/hotspot/share/gc/z/zVirtualMemoryManager.hpp
>
> Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
lgtm.
-------------
Marked as reviewed by aboldtch (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24547#pullrequestreview-2755960462
From stefank at openjdk.org Thu Apr 10 09:20:58 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 10 Apr 2025 09:20:58 GMT
Subject: RFR: 8350441: ZGC: Overhaul Page Allocation [v2]
In-Reply-To: <lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
References: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
<lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
Message-ID: <peH9mHL6RuJ4rX5DNDjf5tdUudOi0pvIWE2hevpy1IY=.0094e6fe-64a1-48dd-8c69-89e36e1c6709@github.com>
On Thu, 10 Apr 2025 09:16:56 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>>> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
>>
>> # Background
>>
>> This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
>>
>> In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
>>
>> # Mapped Cache
>>
>> The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
>>
>> The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
>>
>> # Fragmentation
>>
>> Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
>>
>> ## Virtual Memory Shuffling
>>
>> In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with vir...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Update src/hotspot/share/gc/z/zVirtualMemoryManager.hpp
>
> Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
Looks good!
Marked as reviewed by stefank (Reviewer).
-------------
Marked as reviewed by stefank (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24547#pullrequestreview-2755953546
PR Review: https://git.openjdk.org/jdk/pull/24547#pullrequestreview-2755957917
From eosterlund at openjdk.org Thu Apr 10 09:31:37 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 10 Apr 2025 09:31:37 GMT
Subject: RFR: 8350441: ZGC: Overhaul Page Allocation [v2]
In-Reply-To: <lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
References: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
<lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
Message-ID: <dyRWK0LgMjFFZTqxjr4Rd-Mj45ZKjub2eZd28IbVZm0=.a298f734-0244-482e-b423-0dd11169360c@github.com>
On Thu, 10 Apr 2025 09:20:58 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>>> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
>>
>> # Background
>>
>> This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
>>
>> In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
>>
>> # Mapped Cache
>>
>> The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
>>
>> The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
>>
>> # Fragmentation
>>
>> Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
>>
>> ## Virtual Memory Shuffling
>>
>> In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with vir...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Update src/hotspot/share/gc/z/zVirtualMemoryManager.hpp
>
> Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
Looks good.
-------------
Marked as reviewed by eosterlund (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24547#pullrequestreview-2756002581
From ihse at openjdk.org Thu Apr 10 09:45:56 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 10 Apr 2025 09:45:56 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v2]
In-Reply-To: <wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
<wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
Message-ID: <GlAmyjF3ZmTQHUhkTXRmmrijCWM_4JoredRJOuyVyIc=.775fbc8d-80da-4b0b-b2e1-e5b7e75b3d52@github.com>
On Wed, 13 Sep 2023 17:38:28 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> JDK .properties files still use ISO-8859-1 encoding with escape sequences. It would improve readability to see the native characters instead of escape sequences (especially for the L10n process). The majority of files changed are localized resource files.
>>
>> This change converts the Unicode escape sequences in the JDK .properties files (both in src and test) to UTF-8 native characters. Additionally, the build logic is adjusted to read the .properties files in UTF-8 while generating the ListResourceBundle files.
>>
>> The only escape sequence not converted was `\u0020` as this is used to denote intentional trailing white space. (E.g. `key=This is the value:\u0020`)
>>
>> The conversion was done using native2ascii with options `-reverse -encoding UTF-8`.
>>
>> If this PR is integrated, the IDE default encoding for .properties files need to be updated to UTF-8. (IntelliJ IDEA locks .properties files as ISO-8859-1 unless manually changed).
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>
> Replace InputStreamReader with BufferedReader
Thanks for checking!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2792170460
From jsikstro at openjdk.org Thu Apr 10 11:40:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 10 Apr 2025 11:40:51 GMT
Subject: RFR: 8350441: ZGC: Overhaul Page Allocation [v2]
In-Reply-To: <lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
References: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
<lzvIkusKXs9dzKZHpwAF3_pbvGgMnYQDsATN8vouAwg=.21d063eb-73ff-4cc4-b878-cfb1e298d78d@github.com>
Message-ID: <2lZljOaRU4QYWP-iNYwwFNazf7Z6Jh9MrYxc4QSsNmE=.cae1bf9f-c0af-4c82-ac4b-2ca7a401f6c0@github.com>
On Thu, 10 Apr 2025 09:20:58 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>>> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
>>
>> # Background
>>
>> This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
>>
>> In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
>>
>> # Mapped Cache
>>
>> The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
>>
>> The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
>>
>> # Fragmentation
>>
>> Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
>>
>> ## Virtual Memory Shuffling
>>
>> In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with vir...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>
> Update src/hotspot/share/gc/z/zVirtualMemoryManager.hpp
>
> Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>
Thank you to everyone who contributed to, helped out, and reviewed this patch. I am really happy with how this turned out and all the things I've learned along the way :)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24547#issuecomment-2792450995
From jsikstro at openjdk.org Thu Apr 10 11:40:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 10 Apr 2025 11:40:51 GMT
Subject: Integrated: 8350441: ZGC: Overhaul Page Allocation
In-Reply-To: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
References: <X60C8g2b1RzNOGpr4yx2c7csioVbAL0PjQnwhDToFNc=.65452700-035c-4782-8d83-c42ebc26b333@github.com>
Message-ID: <5hnAuZLpGYPMwR594K0ftHzhCa4PWvwrVMEneZnJ9v4=.f894e7f2-8733-49ae-a875-0e1a6b5ff075@github.com>
On Wed, 9 Apr 2025 13:37:16 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:
>> Note that any reference to pages from here on out refers to the concept of a heap region in ZGC, not pages in the operating system (OS), unless stated otherwise.
>
> # Background
>
> This PR addresses fragmentation by introducing a Mapped Cache that replaces the Page Cache in ZGC. The largest limitation of the Page Cache is that it is constrained by the abstraction of what a page is. The proposed Mapped Cache removes this limitation by decoupling memory from pages, allowing it to merge and split memory in ways that the Page Cache is not suited for. To facilitate the transition, much of the Page Allocator has been redesigned to work with the Mapped Cache.
>
> In addition to fighting fragmentation, the new approach improves NUMA-support and simplifies memory unampping. Combined, these changes lay the foundation for even more improvements in ZGC, like replacing multi-mapped memory with anonymous memory.
>
> # Mapped Cache
>
> The main benefit of the Mapped Cache is that adjacent virtual memory ranges in the cache can be merged to create larger ranges, enabling larger allocation requests to succeed more easily. Most notably, it allows allocations to succeed more often without "harvesting" smaller, discontiguous ranges. Harvesting negatively impacts both fragmentation and latency, as it requires remapping memory into a new contiguous virtual address range. Fragmentation becomes especially problematic in long-running programs and in environments with limited address space, where finding large contiguous regions can be difficult and may lead to premature Out Of Memory Errors (OOME).
>
> The Mapped Cache uses a self-balancing binary search tree to store memory ranges. Since the ranges are unused when inside the cache, the tree can use this memory to store metadata about itself, referred to as intrusive storage. This approach eliminates the need for dynamic memory allocation (e.g., malloc), which could otherwise introduce a latency overhead.
>
> # Fragmentation
>
> Currently, ZGC has multiple strategies for dealing with fragmentation. In some edge cases, these strategies are not as efficient as we would like. By addressing fragmentation differently with the Mapped Cache, ZGC is in a better position to avoid edge cases, which are bad even if they occur only once. This is especially impactful for programs running with a large heap.
>
> ## Virtual Memory Shuffling
>
> In addition to the Mapped Cache, we have made some adjustments in how ZGC deals with virtual memory. When harvesting memory, whic...
This pull request has now been integrated.
Changeset: 7e69b98e
Author: Joel Sikstr?m <jsikstro at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/7e69b98e0548803b85b04b518929c073f8ffaf8c
Stats: 12052 lines in 118 files changed: 7936 ins; 3218 del; 898 mod
8350441: ZGC: Overhaul Page Allocation
Co-authored-by: Axel Boldt-Christmas <aboldtch at openjdk.org>
Co-authored-by: Erik ?sterlund <eosterlund at openjdk.org>
Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Co-authored-by: Stefan Johansson <sjohanss at openjdk.org>
Reviewed-by: stefank, aboldtch, eosterlund
-------------
PR: https://git.openjdk.org/jdk/pull/24547
From jwaters at openjdk.org Thu Apr 10 15:17:42 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 10 Apr 2025 15:17:42 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: <ZchP4xThRkQtuGo4qHmBbNgGnWfHZHoxwDt5dcMyuEw=.6a061de9-a9b8-47f7-b846-72babc6899aa@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
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2794181603
From sspitsyn at openjdk.org Thu Apr 10 16:45:39 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 16:45:39 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v3]
In-Reply-To: <ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
Message-ID: <gIKWpBz7HZJBpYeCDwaXW095H2GQc6NCJzwzBHNY-zg=.1022a7c3-f34f-46f5-8354-7732d0f3e48b@github.com>
On Thu, 10 Apr 2025 05:50:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> review: minor tweak in two similar comments
David, thank you for review!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24539#issuecomment-2794493038
From lmesnik at openjdk.org Thu Apr 10 17:40:25 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 10 Apr 2025 17:40:25 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v3]
In-Reply-To: <ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
Message-ID: <oDvsVETBOkfr2bbWvtAelp1_ZJbv-TTUexYa8It7JH0=.69385e71-660f-4812-bdbc-6161cf4e68bc@github.com>
On Thu, 10 Apr 2025 05:50:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> review: minor tweak in two similar comments
Marked as reviewed by lmesnik (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24539#pullrequestreview-2757715386
From sspitsyn at openjdk.org Thu Apr 10 17:59:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 17:59:15 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v4]
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
fix a build time error for minimal VM config
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24539/files
- new: https://git.openjdk.org/jdk/pull/24539/files/f0b70372..908de6c0
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24539&range=03
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24539&range=02-03
Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
Patch: https://git.openjdk.org/jdk/pull/24539.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24539/head:pull/24539
PR: https://git.openjdk.org/jdk/pull/24539
From sspitsyn at openjdk.org Thu Apr 10 17:59:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 17:59:15 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v3]
In-Reply-To: <ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<ETZyTrta0Gr7ODevqb0gB5s7u8ORvnHXI3pNv4w1bCw=.c6f7689c-e668-47ae-a866-5905ecb6684d@github.com>
Message-ID: <p93agOpqtLB-WRpTkXI8NV6au5_bq_txvlrPyCRk6_0=.2094748d-2a95-4942-837b-98f279531083@github.com>
On Thu, 10 Apr 2025 05:50:23 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> review: minor tweak in two similar comments
I've pushed a minor update to fix a build time error for minimal VM.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24539#issuecomment-2794701655
From jlu at openjdk.org Thu Apr 10 18:47:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 10 Apr 2025 18:47:53 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
native [v2]
In-Reply-To: <0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
References: <FLJUcoMTKEHcWQyslyz5MmH36l2DJESXgsvvSTpQVGI=.33d28019-5a2a-4a0e-8f99-d89b39dbf86e@github.com>
<wnD0vkZ1qWZcUbEguZ4ixnJYH0tEx3b960Vxv6dcqRw=.3140a102-55c6-4ec4-bea9-3a9deca7e852@github.com>
<0q0gTsqIsYtmzAfNYbBXksUXKdZh2uzQ9yvSETKAP88=.137372e6-d63e-4539-b196-4bd9ef1ddd16@github.com>
Message-ID: <9aQcWun5KNgHgELVwkc3478_RtqfhRL1Cxvyn2Yl0Nw=.07ee596f-e738-4796-8d27-14621ed8860c@github.com>
On Thu, 10 Apr 2025 08:44:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:
>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Replace InputStreamReader with BufferedReader
>
> FWIW, I checked out the revision of the commit previous to this change and found the following:
>
>
> % git checkout b55e418a077791b39992042411cde97f68dc39fe^
> % find src -name "*.properties" | xargs file | grep -v ASCII
> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Encodings.properties:
> ISO-8859 text
> src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties:
> Unicode text, UTF-8 text, with very long lines (322)
>
>
> Which indicates that that this is the only non-ASCII, non-UTF-8 property file. So we may be lucky.
This conversion was performed under the assumption of ASCII set and Unicode escape sequences, which is the format we expect for the translation process for .properties files. That file should have been omitted from this change. Thank you @eirbjo and @magicus for the analysis and checking!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/15694#issuecomment-2794828598
From lmesnik at openjdk.org Thu Apr 10 20:08:42 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 10 Apr 2025 20:08:42 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v4]
In-Reply-To: <MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
Message-ID: <VEnVd0RdtDgTtzWlgmTerwt7y3DVa5xXuC-WX_f_HcQ=.f6c50700-537b-4de7-962c-cead10934676@github.com>
On Thu, 10 Apr 2025 17:59:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> fix a build time error for minimal VM config
Marked as reviewed by lmesnik (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24539#pullrequestreview-2758233083
From cjplummer at openjdk.org Thu Apr 10 20:12:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Apr 2025 20:12:13 GMT
Subject: RFR: 8353953: con/sun/jdi tests should be fixed to not always require
includevirtualthreads=y
Message-ID: <0CcAQV1gET_93X0Z8Fkh9yy9xaEhXC1kGcS4QC90izg=.e29b1fc3-b00c-4f86-92cc-b3060c27de41@github.com>
Don't use includevirtualthreads=y unless the test requires it. Debuggers don't usually use includevirtualthreads=y, so we should be doing most of our testing without it. The only reason tests use it is because some tests need it so they can find virtual threads in the debuggee by using vm.allThreads(). This change limits the use of includevirtualthreads=y to just those com/sun/jdi tests that need it.
Tested by running com/sun/jdi tests on all supported platforms in both platform threads mode and virtual threads mode. Also tested with tier1 CI.
-------------
Commit messages:
- Don't use includevthreads=y unless the test requires it.
Changes: https://git.openjdk.org/jdk/pull/24583/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24583&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353953
Stats: 16 lines in 4 files changed: 9 ins; 0 del; 7 mod
Patch: https://git.openjdk.org/jdk/pull/24583.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24583/head:pull/24583
PR: https://git.openjdk.org/jdk/pull/24583
From cjplummer at openjdk.org Thu Apr 10 20:31:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Apr 2025 20:31:13 GMT
Subject: RFR: 8353953: con/sun/jdi tests should be fixed to not always
require includevirtualthreads=y [v2]
In-Reply-To: <0CcAQV1gET_93X0Z8Fkh9yy9xaEhXC1kGcS4QC90izg=.e29b1fc3-b00c-4f86-92cc-b3060c27de41@github.com>
References: <0CcAQV1gET_93X0Z8Fkh9yy9xaEhXC1kGcS4QC90izg=.e29b1fc3-b00c-4f86-92cc-b3060c27de41@github.com>
Message-ID: <eRm_5JePF8bw-o7murXv3pJ29jJW7mzFrrxSqaSpXUA=.eeb757ce-a4ca-48a0-88f9-3988200b2a55@github.com>
> Don't use includevirtualthreads=y unless the test requires it. Debuggers don't usually use includevirtualthreads=y, so we should be doing most of our testing without it. The only reason tests use it is because some tests need it so they can find virtual threads in the debuggee by using vm.allThreads(). This change limits the use of includevirtualthreads=y to just those com/sun/jdi tests that need it.
>
> Tested by running com/sun/jdi tests on all supported platforms in both platform threads mode and virtual threads mode. Also tested with tier1 CI.
Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
Fix copyright.
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24583/files
- new: https://git.openjdk.org/jdk/pull/24583/files/bcb0d8fa..69ce42c3
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24583&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24583&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24583.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24583/head:pull/24583
PR: https://git.openjdk.org/jdk/pull/24583
From cjplummer at openjdk.org Thu Apr 10 20:32:34 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Apr 2025 20:32:34 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v4]
In-Reply-To: <MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
Message-ID: <OancHAGuN2gJwqyjIiOCxg5HfAEO_pzUyTljQudQhc4=.35698ac9-a74d-4fc1-8f89-ce06e0ef14c3@github.com>
On Thu, 10 Apr 2025 17:59:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> fix a build time error for minimal VM config
Marked as reviewed by cjplummer (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24539#pullrequestreview-2758302537
From dholmes at openjdk.org Thu Apr 10 21:02:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 10 Apr 2025 21:02:42 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v4]
In-Reply-To: <MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
Message-ID: <szSYZrXWl4_yLPLeuM0Qv3McZ-wOij8xU07ERWjaOvg=.e26e08ca-3bcc-4844-9900-00847b00590b@github.com>
On Thu, 10 Apr 2025 17:59:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> fix a build time error for minimal VM config
Marked as reviewed by dholmes (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/24539#pullrequestreview-2758408271
From duke at openjdk.org Thu Apr 10 21:34:30 2025
From: duke at openjdk.org (Hendrik Schick)
Date: Thu, 10 Apr 2025 21:34:30 GMT
Subject: RFR: 8353953: con/sun/jdi tests should be fixed to not always
require includevirtualthreads=y [v2]
In-Reply-To: <eRm_5JePF8bw-o7murXv3pJ29jJW7mzFrrxSqaSpXUA=.eeb757ce-a4ca-48a0-88f9-3988200b2a55@github.com>
References: <0CcAQV1gET_93X0Z8Fkh9yy9xaEhXC1kGcS4QC90izg=.e29b1fc3-b00c-4f86-92cc-b3060c27de41@github.com>
<eRm_5JePF8bw-o7murXv3pJ29jJW7mzFrrxSqaSpXUA=.eeb757ce-a4ca-48a0-88f9-3988200b2a55@github.com>
Message-ID: <czg6oPBpZsbrDbGZkNqxwzUNAsghWdtP_Q_Cx4ky_0U=.f9f6b2e2-6f7f-4b32-b01c-08164f5cd8d0@github.com>
On Thu, 10 Apr 2025 20:31:13 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> Don't use includevirtualthreads=y unless the test requires it. Debuggers don't usually use includevirtualthreads=y, so we should be doing most of our testing without it. The only reason tests use it is because some tests need it so they can find virtual threads in the debuggee by using vm.allThreads(). This change limits the use of includevirtualthreads=y to just those com/sun/jdi tests that need it.
>>
>> Tested by running com/sun/jdi tests on all supported platforms in both platform threads mode and virtual threads mode. Also tested with tier1 CI.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>
> Fix copyright.
test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java line 1:
> 1: /*
update copyright to 2025 here aswell?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24583#discussion_r2038371614
From sspitsyn at openjdk.org Thu Apr 10 22:37:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 10 Apr 2025 22:37:27 GMT
Subject: RFR: 8352773: JVMTI should disable events during java upcalls [v4]
In-Reply-To: <MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
<MVh6XNTw4Xb8WTRDRza9jKWWJCyu6CaxuFw3OwHyTN0=.24ab02dc-e8de-4093-ae44-8a268d20f800@github.com>
Message-ID: <ZYE7PTyWpA7sbPFcXjlo89kkJGueBAkzsXlJknOMJPA=.c7ff875f-b27f-41b5-a0e4-9b3e4cc04290@github.com>
On Thu, 10 Apr 2025 17:59:15 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
>> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
>> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
>> Some specific implementation details can be added to the first PR comment.
>>
>> Testing:
>> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
>> - the assert described above is fired if the fix of JDK-8352088 is removed
>> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
>> - Ran mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>
> fix a build time error for minimal VM config
Chris, thank you for review! Thank you for re-approvals guys!
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24539#issuecomment-2795317111
From cjplummer at openjdk.org Thu Apr 10 23:28:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Apr 2025 23:28:24 GMT
Subject: RFR: 8353953: con/sun/jdi tests should be fixed to not always
require includevirtualthreads=y [v3]
In-Reply-To: <0CcAQV1gET_93X0Z8Fkh9yy9xaEhXC1kGcS4QC90izg=.e29b1fc3-b00c-4f86-92cc-b3060c27de41@github.com>
References: <0CcAQV1gET_93X0Z8Fkh9yy9xaEhXC1kGcS4QC90izg=.e29b1fc3-b00c-4f86-92cc-b3060c27de41@github.com>
Message-ID: <mpF-oKa125btZzRBzX1S6iIPhomVU4F-hy50-dK8SPs=.4e0ca5b0-653a-4af2-9828-5e4d56001ff3@github.com>
> Don't use includevirtualthreads=y unless the test requires it. Debuggers don't usually use includevirtualthreads=y, so we should be doing most of our testing without it. The only reason tests use it is because some tests need it so they can find virtual threads in the debuggee by using vm.allThreads(). This change limits the use of includevirtualthreads=y to just those com/sun/jdi tests that need it.
>
> Tested by running com/sun/jdi tests on all supported platforms in both platform threads mode and virtual threads mode. Also tested with tier1 CI.
Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
Fix copyright.
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/24583/files
- new: https://git.openjdk.org/jdk/pull/24583/files/69ce42c3..8193ccb5
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=24583&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=24583&range=01-02
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/24583.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24583/head:pull/24583
PR: https://git.openjdk.org/jdk/pull/24583
From cjplummer at openjdk.org Thu Apr 10 23:28:25 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 10 Apr 2025 23:28:25 GMT
Subject: RFR: 8353953: con/sun/jdi tests should be fixed to not always
require includevirtualthreads=y [v2]
In-Reply-To: <czg6oPBpZsbrDbGZkNqxwzUNAsghWdtP_Q_Cx4ky_0U=.f9f6b2e2-6f7f-4b32-b01c-08164f5cd8d0@github.com>
References: <0CcAQV1gET_93X0Z8Fkh9yy9xaEhXC1kGcS4QC90izg=.e29b1fc3-b00c-4f86-92cc-b3060c27de41@github.com>
<eRm_5JePF8bw-o7murXv3pJ29jJW7mzFrrxSqaSpXUA=.eeb757ce-a4ca-48a0-88f9-3988200b2a55@github.com>
<czg6oPBpZsbrDbGZkNqxwzUNAsghWdtP_Q_Cx4ky_0U=.f9f6b2e2-6f7f-4b32-b01c-08164f5cd8d0@github.com>
Message-ID: <WnPNpzKIboDSEtdyyGyGCwht9N87wdyeDXD0kMdP8AI=.1e53dbda-fd4d-42ee-9fea-68015111e489@github.com>
On Thu, 10 Apr 2025 21:32:05 GMT, Hendrik Schick <duke at openjdk.org> wrote:
>> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Fix copyright.
>
> test/jdk/com/sun/jdi/RedefineNestmateAttr/TestNestmateAttr.java line 1:
>
>> 1: /*
>
> update copyright to 2025 here aswell?
Fixed.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24583#discussion_r2038541169
From sspitsyn at openjdk.org Fri Apr 11 01:28:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 11 Apr 2025 01:28:42 GMT
Subject: Integrated: 8352773: JVMTI should disable events during java upcalls
In-Reply-To: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
References: <Ib4hLHiEpqdXHK8pe4X7EVxkmqsIGr5Ss9G4C7G-MHE=.c7084feb-78e5-4e16-ad51-e72bbab0f6a0@github.com>
Message-ID: <VYqKVsfwidWWoea9cwWXh5m9R-bbsC22dzP-gwBjV5U=.01b38e6b-5483-4325-a73b-f23e4ade7562@github.com>
On Wed, 9 Apr 2025 08:14:04 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:
> As noted in [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088), JVMTI `GetThreadGroupChildren` does an upcall to java. This results in a`ClassPrepare` event the first time it does this, and these events can cause problems (deadlocks) for the debugger or debug agent. The [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088) was fixed to get rid of class loading during Java upcall from `GetThreadGroupChildren`. However, some other events can be generated as well. It is more safe to disable all JVMTI events during debugger-related upcalls originated by JVMTI.
> The `ClassPrepare` events are important for the debug agent. So, an assert was added into `ClassPrepare` event generation to make sure there are no attempts to post this event during upcalls.
> Some specific implementation details can be added to the first PR comment.
>
> Testing:
> - Verified with the test `jdk/com/sun/jdi/EarlyThreadGroupChildrenTest.java` that was added with the fix of [JDK-8352088](https://bugs.openjdk.org/browse/JDK-8352088):
> - the assert described above is fired if the fix of JDK-8352088 is removed
> - the test is passed without if the fix of JDK-8352088 is removed and the assert is removed
> - Ran mach5 tiers 1-6
This pull request has now been integrated.
Changeset: 1c34f3cd
Author: Serguei Spitsyn <sspitsyn at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/1c34f3cdb1df1b9bd01c6795e19a78753e3b555a
Stats: 39 lines in 6 files changed: 37 ins; 0 del; 2 mod
8352773: JVMTI should disable events during java upcalls
Reviewed-by: lmesnik, dholmes, cjplummer, coleenp
-------------
PR: https://git.openjdk.org/jdk/pull/24539
From cjplummer at openjdk.org Fri Apr 11 23:29:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Apr 2025 23:29:38 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
includevirtualthreads=y
Message-ID: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
This is just a preliminary review. I'd like to get some approval for the approach I'm taking. There are over 300 tests that need to be fixed. I've just fixed a handful in this PR to give a feel for the changes I plan on making. If they look ok to you, then I'll update this PR with the needed changes to the rest of the tests.
What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n. There are nearly 1200 nsk/jdi tests. Only about 350 actually need includevirtualthreads=y. I plan making includevirtualthreads=n the default for nsk/jdi tests unless the test does something to override the default and request includevirtualthreads=y.
includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
-------------
Commit messages:
- get rid of commented out change
- Don't always use includevirtualthreads=y
Changes: https://git.openjdk.org/jdk/pull/24606/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24606&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8353955
Stats: 36 lines in 18 files changed: 34 ins; 0 del; 2 mod
Patch: https://git.openjdk.org/jdk/pull/24606.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/24606/head:pull/24606
PR: https://git.openjdk.org/jdk/pull/24606
From cjplummer at openjdk.org Fri Apr 11 23:29:38 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 11 Apr 2025 23:29:38 GMT
Subject: RFR: 8353955: nsk/jdi tests should be fixed to not always require
includevirtualthreads=y
In-Reply-To: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
References: <YJ_c4nAsHMnPhY72Ulc-IOiAJ8NByShjdq_AsrUPHks=.619d0822-251f-4a4b-8a00-3accdcd7ccc0@github.com>
Message-ID: <SVYoRcVyCdibeiWZnPpSgvnJvjcMANj6Cn99szIK-lQ=.320b6b5f-1384-4cf7-b0d4-1be78e7b2c97@github.com>
On Fri, 11 Apr 2025 23:23:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
> This is just a preliminary review. I'd like to get some approval for the approach I'm taking. There are over 300 tests that need to be fixed. I've just fixed a handful in this PR to give a feel for the changes I plan on making. If they look ok to you, then I'll update this PR with the needed changes to the rest of the tests.
>
> What this PR is fixing is the issue with all of our nsk/jdi testing being done with includevirtualthreads=y even though debuggers typically use the default includevirtualthreads=n. As a result we have a testing gap with includevirtualthreads=n. There are nearly 1200 nsk/jdi tests. Only about 350 actually need includevirtualthreads=y. I plan making includevirtualthreads=n the default for nsk/jdi tests unless the test does something to override the default and request includevirtualthreads=y.
>
> includevirtualthreads=y forces the debug agent to track all virtual threads so they are returned by vm.allThreads(). Some tests need this since they use vm.allThreads() to find the debuggee threads. Without includevirtualthreads=y, vm.allThreads() usually won't return any virtual threads (although it might return some for which events have been triggered).
Regarding the SerialExecutionDebugger change, some background might help. The following tests all use SerialExecutionDebugger:
vmTestbase/nsk/jdi/stress/serial/forceEarlyReturn001/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/forceEarlyReturn002/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/heapwalking002/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/mixed001/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/mixed002/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/monitorEvents001/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/monitorEvents002/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/ownedMonitorsAndFrames001/TestDescription.java
vmTestbase/nsk/jdi/stress/serial/ownedMonitorsAndFrames002/TestDescription.java
Each of these tests has a set of existing tests (subtests) that will be executed using the same debugger and debuggee processes. They are executed either in a random order (shuffle) or for a large number of iterations, both with a goal of being somewhat stressful. There is a .tests file that specifies the subtests to run and how to run them. For example, for vmTestbase/nsk/jdi/stress/serial/forceEarlyReturn002 we have:
OPTIONS:shuffle
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn001.forceEarlyReturn001
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn002.forceEarlyReturn002
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn003.forceEarlyReturn003
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn004.forceEarlyReturn004
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn005.forceEarlyReturn005
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn008.forceEarlyReturn008
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn013.forceEarlyReturn013
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn014.forceEarlyReturn014
Some of the subtests requiring launching the debug agent with includevirtualthreads=y. Usually the subtest would be managing this and making sure the debug agent is launched with includevirtualthreads=y. However, for subtests run by the SerialExecutionDebugger, it is the SerialExecutionDebugger class that is responsible launching the debug agent, not the test, and therefore the subtest has no way to enforce its requirement for includevirtualthreads=y. It turns out there is only subtest that needs includevirtualthreads=y:
nsk.jdi.ThreadReference.forceEarlyReturn.forceEarlyReturn001.forceEarlyReturn002
You can see the fix for this test in this PR, but as pointed out above, this will only work when these test is run individually, not when run by SerialExecutionDebugger. Since SerialExecutionDebugger launches the debuggee, it needs to know whether or not to specify includevirtualthreads=y. At first I had it just always do that, but it was unnecessary for most of the tests, and reduced test coverage with includevirtualthreads=n. I then opted to add support for passing -includevirtualthreads to SerialExecutionDebugger. That way it's only necessary for the tests that include forceEarlyReturn002. If I want to take this further, I could add an additional @run command that does not use -includevirtualthreads, and also has a separate .test list that excludes forceEarlyReturn002, but I don't think this adds enough benefit to be worth while.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24606#issuecomment-2798204267