From sspitsyn at openjdk.org  Wed Oct  1 00:01:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Oct 2025 00:01:25 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <pW9wtSPU8bQGqssN648DfvlwFj3yuTZhhYX8oJHHqDs=.05987cbc-8373-4284-bfef-f964999313d9@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <pW9wtSPU8bQGqssN648DfvlwFj3yuTZhhYX8oJHHqDs=.05987cbc-8373-4284-bfef-f964999313d9@github.com>
Message-ID: <kvidccWQsJPicTUkwwOlKJsG9E6FY2Y183M5Ix0sAWA=.79ff5f67-9c36-4044-8013-8eedbc06a12f@github.com>

On Mon, 29 Sep 2025 08:45:05 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
>> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
>> 
>> However, current implementation changes state and only after this start disabling events.  
>> 
>> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
>> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
>> 
>> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
>> 
>> After this fix the VMDeath callback also can't generate any events. 
>> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
>> 
>> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
>> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
>> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.
>
> Hi Leonid,
> 
> We currently have a shutdown issue where the GC is shut down before the last JVMTI events are sent from the same thread. The problem is that the JVMTI code allocates Java objects, which is problematic given that we've just shut down the GC threads.
> 
> Because of this extra allocation we have added a stop-gap solution that is not what we want long-term, but it fixes some reoccuring issue that was reported. The real solution involves switching the order between shutting down the GC threads and sending the last JVMTI event.
> 
> Take a look at before_exit in java.cpp:
> 
>   // Run before exit and then stop concurrent GC threads
>   Universe::before_exit();
> 
> ... // some unrelated code ...
> 
>   if (JvmtiExport::should_post_thread_life()) {
>     JvmtiExport::post_thread_end(thread);
>   }
> 
>   // Always call even when there are not JVMTI environments yet, since environments
>   // may be attached late and JVMTI must track phases of VM execution
>   JvmtiExport::post_vm_death();
>   JvmtiAgentList::unload_agents();
> 
> 
> The GC team thinks that the thread that shuts down the GC threads should not call code that allocates, so we would like to hoist the JVMTI code to before the code that stops the GC threads
> 
> ... // some unrelated code ...
> 
>   if (JvmtiExport::should_post_thread_life()) {
>     JvmtiExport::post_thread_end(thread);
>   }
> 
>   // Always call even when there are not JVMTI environments yet, since environments
>   // may be attached late and JVMTI must track phases of VM execution
>   JvmtiExport::post_vm_death();
>   JvmtiAgentList::unload_agents();
> 
>   // Run before exit and then stop concurrent GC threads
>   Universe::before_exit();
> 
> 
> There's a JBS entry created for the issue described above:
> https://bugs.openjdk.org/browse/JDK-8367902
> 
> Given that you have looked into this VMDeath code and proposes a change to it, maybe you could help reasoning about if the above reordering would fit into what you proposes here in this PR?

@stefank :
> Given that you have looked into this VMDeath code and proposes a change to it, maybe you could help reasoning about if the above reordering would fit into what you proposes here in this PR?

@lmesnik :
> The VM Death call back is still valid point to call any java code. So the GC should be active at this point. I quickly check that 'Universe::before_exit()' doesn't post any jvmti events, so it makes sense to call it after vm death.

Stefan, I agree with Leonid that your reordering suggestion is reasonable.

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

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3354166387

From sspitsyn at openjdk.org  Wed Oct  1 00:15:29 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 1 Oct 2025 00:15:29 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <gyuymB0UMTeh2hQghiKBZehWkvMCsS60CcHlhynjqUM=.43e86c2a-bf5e-475d-8751-43b7b9abdb45@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> The proposed fix to disable all event generation and then post the last (VMDeath) event. After this event is completed  change VM phase to death. It's guaranteed that no any events are generated after VMDeath completion.
> 
> After this fix the VMDeath callback also can't generate any events. 
> The alternative is to disable events posting after VMDeath completion and before changing VM state. However, seems it is still a gap between vm death event completion and disabling events. So user can see events after VMDeath completion.
> 
> It might be still possible also to wait while all currently executing  events are completed. It is not required be specification, might add unneeded complexity. So  I want to apply this fix first and then to check if we still any problems.
> Then, I plan to wait with timeout until all current (and queued) jvmti events are completed with some reasonable timeout.
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

It is a nice move to a right direction in fixing this long standing issue, so thank you for attacking it now! It should fix all WRONG_PHASE failures we are constantly observing with our mach5 test runs. We had and fixed a similar issue in the JDWP agent a long time ago, so a similar approach can be used here. Disabling all JVMTI events (except the VM_DEATH) is one part of the solution. Another part is that we should wait for all agent callbacks in progress to complete their work at the VM_DEATH point before the VM_DEATH event is posted. I see it has been already discussed in the PR comments. I'd suggest to consider to handle it here.

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

PR Review: https://git.openjdk.org/jdk/pull/27504#pullrequestreview-3287099388

From jsjolen at openjdk.org  Wed Oct  1 08:58:17 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 1 Oct 2025 08:58:17 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v10]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <tq4CL4-ZkV-e9cFYBsbXGsNQ8_UnTpF-c-ZAbbX4PJU=.835545e4-3c67-4c62-9c7e-1b38e92bdf4a@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/operands-again' into operands-again
 - Use int to avoid cast

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/5a42b0df..55f6d5bc

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

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

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

From dholmes at openjdk.org  Wed Oct  1 11:23:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Oct 2025 11:23:00 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <KI7OHrB3KP02r2LDX32_Xeinnn9WZBsJhsUvbREvmiI=.273ee2f6-0dab-4cc7-a4c8-8e3df0c46e1c@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
 <KI7OHrB3KP02r2LDX32_Xeinnn9WZBsJhsUvbREvmiI=.273ee2f6-0dab-4cc7-a4c8-8e3df0c46e1c@github.com>
Message-ID: <kdni1lxL0cpKATN-cAVl7PTbsGc1DL7zupWAnJgRPSg=.06af3a79-80a8-4711-be29-b476022ce28a@github.com>

On Tue, 30 Sep 2025 15:38:49 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Right now I am not sure if CSR is needed. The new behaviour doesn't require specification changes.

Significant behavioural changes also require a CSR request - not just changes to specifications.

>> src/hotspot/share/prims/jvmtiEventController.cpp line 1060:
>> 
>>> 1058: void
>>> 1059: JvmtiEventControllerPrivate::vm_death() {
>>> 1060:   _execution_finished = true;
>> 
>> Unless there is some lock guarding this that I cannot see in this diff, if you want to ensure this will be seen as soon as possible then you need a `store_fence` (and the variable should be `volatile` - and will be a candidate for `Atomic<T>`). You are still racing with others threads but this would at least attempt to minimise the window.
>
> I forgot to put this in description and  mentioned the first comment. 
> The access to variable is protected with JvmtiThreadState_lock. 
> Am I understand correctly, that it is enough to correctly synchronize it?

Yes - if all accesses are done under the lock that is fine. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3355863717
PR Review Comment: https://git.openjdk.org/jdk/pull/27504#discussion_r2394227874

From alanb at openjdk.org  Wed Oct  1 12:39:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Oct 2025 12:39:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
Message-ID: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>

On Tue, 30 Sep 2025 11:23:13 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?

I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 

> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?

"genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.

I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.

One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3356108097

From schernyshev at openjdk.org  Wed Oct  1 12:50:49 2025
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Wed, 1 Oct 2025 12:50:49 GMT
Subject: RFR: 8319589: Attach from root to a user java process not
 supported in Mac [v6]
In-Reply-To: <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
References: <cqboyGR_XmsztOsbsbxM_LTUjF6z4aY_wE0if0rWa_E=.7bb79776-3cd4-4368-86f2-169cd2d4c41d@github.com>
 <yfC6vCsyuvKfMK0EpLymvrtVCPXDwhkuoGzhDNad7vM=.efc613a3-25b2-4043-95b3-d49c7b420a24@github.com>
Message-ID: <KirCw5YLLWb0Z-9u_PnWwCvljG1gGde6g46dGSGJnas=.0d3671a4-8d72-4ad9-ac2b-5827e90a116d@github.com>

On Thu, 25 Sep 2025 11:22:05 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Hi all,
>> 
>> I would like to propose a fix for JDK-8319589. This will allow jcmd and jps running as root to get the complete list of JVMs running by all users, and to attach from root to non-root JVMs. Previously, JDK-8197387 introduced the same possibility on Linux.
>> 
>> This change affects macOS, that uses "secure" per-user temporary directories. It only affects JVMs running as root, the behavior in non-privileged JVMs remains unchanged.
>> 
>> Jcmd and jps rely on LocalVmManager to get the initial list of the local VMs. The LocalVmManager uses sun.jvmstat.PlatformSupport to get the list of temp directories, where it searches for user's PerfData directory such as "hsperfdata_<username\>". In macosx the temp directories are per-user, the temp path is returned by confstr(_CS_DARWIN_USER_TEMP_DIR). The per-user directories are mode 700 and so they are read-protected from non-privileged users and can be accessed by the owner and the root.
>> 
>> Both jps and jcmd (HotSpotAttachProvider) create MonitoredVm objects, that have PerfDataBuffer that performs attachment to the target. Only the attachable VMs are listed in jcmd output.
>> 
>> The proposed patch changes the list of directories returned by the PlatformSupport#getTemporaryDirectories() in VMs running as root. The list is later used in VirtualMachineImpl (jdk.attach). It changes also the way mmap_attach_shared() searches for hsperfdata_<username\>/<pid\> files to map the shared memory. Mmap_attach_shared() and VirtualMachineImpl (via PlatformSupport) list the content of /var/folders, where the temp directories are located, more specificly the temp directories are /var/folders/<BUCKET\>/<ENCODED_UUID_UID\>/T as hinted in [1]. The full list is returned by newly added PlatformSupportImpl#getTemporaryDirectories().
>> 
>> The attaching client's VirtualMachineImpl needs the target process's temp directory to find .java<pid\> and create .attach<pid\> files. It uses the list returned by PlatformSupportImpl#getTemporaryDirectories() and the ProcessHandle of the target process to search for user's PerfData directory, e.g. hsperfdata_<username\>, which is in the target process's temp directory, exactly where it expects to see the .java<pid\> in return on sending SIGQUIT to the target VM.
>> 
>> Mmap_attach_shared() traverses the /var/folders in get_user_tmp_dir() and looks for a hsperfdata_<username\> folder. If that folder is found in /var/folders/*/*/T, that means the temp folder corresponds to the <username\> and to t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8319589
>  - Removed unused native method
>  - addressed review comment #2
>  - Apply suggestions from code review
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/jdk.attach/macosx/classes/sun/tools/attach/VirtualMachineImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - addressed review comments
>  - 8319589: Attach from root to a user java process not supported in Mac

@sspitsyn Could you please have a look at this PR ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25824#issuecomment-3356063722

From lmesnik at openjdk.org  Wed Oct  1 15:55:04 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 1 Oct 2025 15:55:04 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <kdni1lxL0cpKATN-cAVl7PTbsGc1DL7zupWAnJgRPSg=.06af3a79-80a8-4711-be29-b476022ce28a@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
 <9Pt3r-dYcnG_IOpxWynEIWfl4EF0ZQVVoQ1CHbstwRo=.ea9be3fe-1143-4615-a26d-8c51f0adbfc0@github.com>
 <KI7OHrB3KP02r2LDX32_Xeinnn9WZBsJhsUvbREvmiI=.273ee2f6-0dab-4cc7-a4c8-8e3df0c46e1c@github.com>
 <kdni1lxL0cpKATN-cAVl7PTbsGc1DL7zupWAnJgRPSg=.06af3a79-80a8-4711-be29-b476022ce28a@github.com>
Message-ID: <SaNt2rD-HOwBDv-Mow5b45a2FmQwXvGQSgBHYLk4EXk=.48adb83b-056e-4b41-805d-a82f65120d64@github.com>

On Wed, 1 Oct 2025 11:20:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Right now I am not sure if CSR is needed. The new behaviour doesn't require specification changes.
> 
> Significant behavioural changes also require a CSR request - not just changes to specifications.

@sspitsyn, @dholmes-ora Thank you for feedback.
Let me implement completed solution that post the VMDeath as a last event and wait for completion of current events before changing phase to dead. 

In this case the code inside any callback can never seen phase dead. The VMDeath is the last posted event. The events happened while VM Death is processed are not posted. No events can be executed concurrently with VMDeath event. 

And I'll prepare CSR for this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3357058759

From cjplummer at openjdk.org  Wed Oct  1 19:58:41 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 Oct 2025 19:58:41 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <rDv_SECSJJdKdeh4K987tsU90IKR9yh_fymfdDWhwt8=.0e2494dd-54f4-4cfd-bfae-8093d0f87016@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
 <ehcFrMx1yM2xiVHt1dunRnDBIiR6MoAwOIfTB7n3gPY=.bb4fcd1f-c501-47c3-a56f-3125a7278b6a@github.com>
 <rDv_SECSJJdKdeh4K987tsU90IKR9yh_fymfdDWhwt8=.0e2494dd-54f4-4cfd-bfae-8093d0f87016@github.com>
Message-ID: <R6bUMayjD5ZYanP3Qq9KfeKT73A-8d4vJs6DsS72T_w=.ad81803c-1409-4122-b51d-ccadf3361f02@github.com>

On Tue, 30 Sep 2025 10:19:46 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 428:
>> 
>>> 426:             lib_memsz += target_vaddr - existing_map->vaddr;
>>> 427:         }
>>> 428: 
>> 
>> I think this change looks good, but just want to make sure I'm understanding it properly. Kevin commented the following:
>> 
>> 
>> hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)
>> 
>>           print_error("address conflict @ 0x%lx (existing map size = %ld, size = %ld, flags = %d)\n",
>>                         target_vaddr, existing_map->memsz, lib_php->p_memsz, lib_php->p_flags);
>> 
>> core has no mapping at exactly 0x7fa9ff0e4440 but has:
>> 
>>   Start                 End               Page Offset
>>   0x00007fa9ff0db000  0x00007fa9ff0e4000  0x0000000000000000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so  (0x9000 size) 0x841c rounded up
>>   0x00007fa9ff0e4000  0x00007fa9ff0fd000  0x0000000000000008 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so (0x19000 size) the existing map size from the error
>> 
>> 
>> So the problem here is that we were expecting 0x00007fa9ff0e4000 but got 0x7fa9ff0e4440. Basically target_vaddr is at an unexpected offset from existing_map->vaddr. The fix is to ad this offset to lib_memsz so the error is no longer triggered. Do we understand why this offset is happening?
>
>>  Do we understand why this offset is happening?
> 
> It looks like the binary is just built differently, clang or the linker or some combination arranges things differently to what we have seen from gcc.
> 
> Maybe it's enough to say there doesn't have to be a 1:1 mapping from program headers to segments in the process.
> We can have a core file segment that contains more than one program header from the library (that 0x19000 size segment at the libjimage base address).
> 
> 
> So, new question: 
> 
> we must have been through this loop already, in the libjimage example with the first LOAD PH of size 0x000000000000841c at the library base address.
> 
> Did that pass the same test?
> No it can't, the mapping is 0x19000 and size 0x841c does not round up to that.
> I think we must ignore the first LOAD PH from the clang build as we check:
> 
> 	408       } else if (lib_php->p_flags != existing_map->flags) {
> 	
> ..and the first LOAD PH from https://bugs.openjdk.org/secure/attachment/116209/3libjimage_all.txt
> ..is a Read only, not execute.
> 
> This should be OK in this case:
> 
> https://bugs.openjdk.org/secure/attachment/116199/3core_all.txt
>   Type           Offset             VirtAddr           PhysAddr
>                  FileSiz            MemSiz              Flags  Align
>   LOAD           0x0000000000141000 0x00007fa9ff0e4000 0x0000000000000000
>                  0x0000000000019000 0x0000000000019000  R E    0x1000				
> 				 
> Filesize and memsiz both 0x019000 must mean the core contains everything, we don't need either of these from the library.
> But there is no harm in continuing past the problematic check and populating existing_map from the library.

Ok. That's mostly making sense to me. I'm still a bit fuzzy on it, but that's ok. Has testing been done to make sure this doesn't break anything with gcc?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2395729935

From fandreuzzi at openjdk.org  Wed Oct  1 20:02:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 1 Oct 2025 20:02:43 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <R6bUMayjD5ZYanP3Qq9KfeKT73A-8d4vJs6DsS72T_w=.ad81803c-1409-4122-b51d-ccadf3361f02@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
 <ehcFrMx1yM2xiVHt1dunRnDBIiR6MoAwOIfTB7n3gPY=.bb4fcd1f-c501-47c3-a56f-3125a7278b6a@github.com>
 <rDv_SECSJJdKdeh4K987tsU90IKR9yh_fymfdDWhwt8=.0e2494dd-54f4-4cfd-bfae-8093d0f87016@github.com>
 <R6bUMayjD5ZYanP3Qq9KfeKT73A-8d4vJs6DsS72T_w=.ad81803c-1409-4122-b51d-ccadf3361f02@github.com>
Message-ID: <7UDa4Ufl2WC3Ofu0nkZ0PGHF3vWtZETpUDrh0RXOaWU=.883b428b-612e-46a1-8a33-0f68b18d3f61@github.com>

On Wed, 1 Oct 2025 19:56:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Has testing been done to make sure this doesn't break anything with gcc?

Yes, I didn't see any problem while testing the change with gcc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27274#discussion_r2395736976

From cjplummer at openjdk.org  Wed Oct  1 21:52:47 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 1 Oct 2025 21:52:47 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
Message-ID: <dywmD--dLnjvLiOT1GSE_4jdF_frwDp8Hq8Ph5o8NG0=.df70b3e6-7546-4b83-a068-4b933be046b6@github.com>

On Mon, 29 Sep 2025 10:50:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27274#pullrequestreview-3291263192

From fandreuzzi at openjdk.org  Wed Oct  1 22:40:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 1 Oct 2025 22:40:47 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v5]
In-Reply-To: <WCa4dCTYFTTzGZtzK25Nk45fclccvMG3vU_KpivOrig=.c5785f6c-3b08-4004-8b6a-66db33853740@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <ozqsz7Yc38Tlhzwj1NBUrL0qo4XkDDzgT__asRetCbw=.98e408b8-a346-4902-ab82-9da1ce30e18c@github.com>
 <WCa4dCTYFTTzGZtzK25Nk45fclccvMG3vU_KpivOrig=.c5785f6c-3b08-4004-8b6a-66db33853740@github.com>
Message-ID: <qrxsclO5uiH5aMayd6y39EoMHWiSz7o6YB4iQ635Pgk=.4f529bd7-778c-4d9e-bfae-0b5a4c220e96@github.com>

On Tue, 23 Sep 2025 14:24:47 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - nn
>>  - comment and rename
>
> Thanks for the additional info.
> 
> If I ignore what's said so far and start again, I see the following...  (anyone should feel free to correct, we aren't in this
> area every day!...)
> 
> hsdb> ERROR: address conflict @ 0x7fa9ff0e4440 (existing map size = 102400, size = 97328, flags = 5)
> 
>           print_error("address conflict @ 0x%lx (existing map size = %ld, size = %ld, flags = %d)\n",
>                         target_vaddr, existing_map->memsz, lib_php->p_memsz, lib_php->p_flags);
> 
> core has no mapping at exactly 0x7fa9ff0e4440 but has:
> 
>   Start                 End               Page Offset
>   0x00007fa9ff0db000  0x00007fa9ff0e4000  0x0000000000000000 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so  (0x9000 size) 0x841c rounded up
>   0x00007fa9ff0e4000  0x00007fa9ff0fd000  0x0000000000000008 /home/fandreuz/code/jdk/build/clang/images/jdk/lib/libjimage.so (0x19000 size) the existing map size from the error
>   
> 
> The error is having a size 0x17c30 mapping that should go at 0x00007fa9ff0e4000
> That is the second LOAD phdr from libjimage.
> 
> The check which has been working for gcc builds:
> ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size)
> 
> 102400 	= 0x19000 is mem size, page size aligned. The core has a mapping of this size.
> 97328	= 0x17c30 libjimage has this, which rounds up to only 0x18000
> 
> libjimage is providing too little data? 
> But target vaddr 0x7fa9ff0e4440 is offset into the actual segment 0x00007fa9ff0e4000 by  0x440  (1088 bytes)
> 
> 0x17c30 + 0x440 = 0x18070 which rounds up to the wanted 0x19000
> 
> 
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c
> 
> 399       uintptr_t target_vaddr = lib_php->p_vaddr + lib_base;
> 400       map_info *existing_map = core_lookup(ph, target_vaddr);
> 
> (Existing code expects target_vaddr and existing_map->vaddr to be exactly equal, not to see target_vaddr being
> anything other than 0x1000 aligned.)
> 
> Maybe we:
> check if target_vaddr > existing_map->vaddr and add any difference to the library mem size we compare?
> 
> 
> 429             (ROUNDUP(existing_map->memsz, page_size) != ROUNDUP(lib_php->p_memsz, page_size))) {
> 
> +        uint64_t lib_memsz = lib_php->p_memsz; // check type
> +        if (target_vaddr > existing_map->vaddr) {
> +            lib_memsz += (target_vaddr - existing_map->vaddr);
> +        }
> +        lib_memsz = ROUNDUP(lib_memsz, page_size);
> +
>          if ((existing_map->memsz != page_size) &&
>              (existing_map->fd != lib_fd) &&
> -            (ROUNDUP(existing_map->memsz, page_s...

Thanks for the review @kevinjwalls and @plummercj !

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3358393761

From duke at openjdk.org  Wed Oct  1 22:40:49 2025
From: duke at openjdk.org (duke)
Date: Wed, 1 Oct 2025 22:40:49 GMT
Subject: RFR: 8367609: serviceability/sa/ClhsdbPmap.java fails when built
 with Clang [v7]
In-Reply-To: <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
 <tMV8FczhYA-t5jdPEOTm4OBj2W3jPGQHH2cBurdYrIg=.2b4e4147-3460-4c95-879c-fdb710cba6a2@github.com>
Message-ID: <xnq1L1MggmTUoWwDR_onhtiu9V4HABOhBiw_2JB1Gr4=.14a2f190-33b2-4747-a11b-c44c56b5b309@github.com>

On Mon, 29 Sep 2025 10:50:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
>> 
>> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
>> 
>> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
>> 
>> I added some files to the ticket for context.
>> 
>> Passes `tier1` and `tier2`.
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27274#issuecomment-3358396306

From amenkov at openjdk.org  Wed Oct  1 23:08:57 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 1 Oct 2025 23:08:57 GMT
Subject: RFR: 8304811:
 vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails
 with JVMTI_ERROR_TYPE_MISMATCH
Message-ID: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>

The change fixes the test which intermittently fails.

The test requests MethodEntry. SingleStep and Breakpoint events globally (from all threads).
MethodEntry handler checks location (to be expected test method);
Breakpoint request specifies location in the testes method, only test threads calls the method;
SingleStep handler has no checks for thread or location. So once SingleStep event is enabled, event from other thread can be posted first (or several events from different threads).
The fix enables SingleStep event only for test thread (we get it in MethodEntry)

testing: tier3

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

Commit messages:
 - fix

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

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

From lmesnik at openjdk.org  Wed Oct  1 23:53:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 1 Oct 2025 23:53:44 GMT
Subject: RFR: 8304811:
 vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails
 with JVMTI_ERROR_TYPE_MISMATCH
In-Reply-To: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
References: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
Message-ID: <D6xSuW8upFhZMeOE2fS7qBOxccnilUbnBOLkK_PsfZI=.0e797677-2de5-4c3d-86c5-ccfab5d9eb9a@github.com>

On Wed, 1 Oct 2025 22:29:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes the test which intermittently fails.
> 
> The test requests MethodEntry. SingleStep and Breakpoint events globally (from all threads).
> MethodEntry handler checks location (to be expected test method);
> Breakpoint request specifies location in the testes method, only test threads calls the method;
> SingleStep handler has no checks for thread or location. So once SingleStep event is enabled, event from other thread can be posted first (or several events from different threads).
> The fix enables SingleStep event only for test thread (we get it in MethodEntry)
> 
> testing: tier3

The fix looks reasonable.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27598#pullrequestreview-3291637304

From dholmes at openjdk.org  Thu Oct  2 00:36:46 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Oct 2025 00:36:46 GMT
Subject: RFR: 8304811:
 vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails
 with JVMTI_ERROR_TYPE_MISMATCH
In-Reply-To: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
References: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
Message-ID: <GoGE4rcg8rSOLi5bRDhu2oJILfTNCABqZetUa19XAWY=.2ff9225c-d820-4901-afd6-395851c82e04@github.com>

On Wed, 1 Oct 2025 22:29:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes the test which intermittently fails.
> 
> The test requests MethodEntry. SingleStep and Breakpoint events globally (from all threads).
> MethodEntry handler checks location (to be expected test method);
> Breakpoint request specifies location in the testes method, only test threads calls the method;
> SingleStep handler has no checks for thread or location. So once SingleStep event is enabled, event from other thread can be posted first (or several events from different threads).
> The fix enables SingleStep event only for test thread (we get it in MethodEntry)
> 
> testing: tier3

I agree this seems reasonable. Though I still wonder why this suddenly started appearing only on linux-aarch64.

Thanks for the quick fix.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27598#pullrequestreview-3291723877

From dlong at openjdk.org  Thu Oct  2 00:54:54 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 00:54:54 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v4]
In-Reply-To: <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <_pqvEs0LIlAc7RjFUwg-bpxS3D2v5U7c6In2sG8XLhQ=.57e3aead-6ac4-4a42-89d2-385d7e6ecedf@github.com>
 <jtd7gfuV5C8sQBsx4bQIhWLFlDnIEyCza6u3foAV4RU=.2b6d7b42-3c1f-41ba-8a8e-056a982ad588@github.com>
Message-ID: <WQD2pKsicEd0OZ7NR_p16ruAhNHwrrjnGYc7h9QGJNk=.a0664e54-6a0e-4900-a1f6-41645c08fae6@github.com>

On Tue, 2 Sep 2025 21:09:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Dean Long 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 'openjdk:master' into 8366461-mh-invoke
>>  - revert whitespace change
>>  - undo debug changes
>>  - cleanup
>>  - arm32 build
>>  - Merge branch 'openjdk:master' into 8366461-mh-invoke
>>  - first pass
>
> Nice cleanup! Looks good.

@iwanowww , I think I need you to re-review the final version.

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3358642300

From dholmes at openjdk.org  Thu Oct  2 04:40:47 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Oct 2025 04:40:47 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v10]
In-Reply-To: <tq4CL4-ZkV-e9cFYBsbXGsNQ8_UnTpF-c-ZAbbX4PJU=.835545e4-3c67-4c62-9c7e-1b38e92bdf4a@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <tq4CL4-ZkV-e9cFYBsbXGsNQ8_UnTpF-c-ZAbbX4PJU=.835545e4-3c67-4c62-9c7e-1b38e92bdf4a@github.com>
Message-ID: <L8dy3dMFkQPnEKkvdQ9T45IsQ5on3IfKZEjQuSWvrjU=.4eb80f72-89ae-4243-ab78-a7f9e063d808@github.com>

On Wed, 1 Oct 2025 08:58:17 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/operands-again' into operands-again
>  - Use int to avoid cast

Nothing further from me. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3292231646

From fandreuzzi at openjdk.org  Thu Oct  2 11:44:56 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 2 Oct 2025 11:44:56 GMT
Subject: Integrated: 8367609: serviceability/sa/ClhsdbPmap.java fails when
 built with Clang
In-Reply-To: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
References: <j2Ebbvr13QK4FctIOvLJP0oH52po4VBc-SYYA3Oyv5o=.dd050841-def5-4057-860f-d3f0c8492d95@github.com>
Message-ID: <vIR5OZbWK3qYNet_GOX99aZ-_oACMiBpwZFLeUOiYBI=.0b6b2c27-1fc6-4e0b-94cf-a68c6d40cadd@github.com>

On Sun, 14 Sep 2025 23:16:00 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The problem seems to be in read_lib_segments (ps_core.c), this check is too harsh:
> 
> https://github.com/openjdk/jdk/blob/5271448b3a013b2e3edcd619a4a3b975b292dae1/src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c#L423-L425
> 
> In my run, `existing_map->memsz = 0xe24000`, while the rhs in L425 is `0xe23000`. According to the NT_FILE entry, this segment of `libjvm.so` has file offset 0x67f000. It seems that the linker aligned it down according to the page size (0x1000). The offset of the same segment according to `readelf -l libjvm.so` is 0x67fc80. This additional offset should be added to `p_memsz` to obtain the 0xe24000, which we see in the core dump.
> 
> I added some files to the ticket for context.
> 
> Passes `tier1` and `tier2`.

This pull request has now been integrated.

Changeset: 8be16160
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8be16160d2a6275ff619ea4cebb725475c646052
Stats:     7 lines in 1 file changed: 6 ins; 0 del; 1 mod

8367609: serviceability/sa/ClhsdbPmap.java fails when built with Clang

Reviewed-by: kevinw, cjplummer

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

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

From sspitsyn at openjdk.org  Thu Oct  2 15:13:22 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 2 Oct 2025 15:13:22 GMT
Subject: RFR: 8304811:
 vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails
 with JVMTI_ERROR_TYPE_MISMATCH
In-Reply-To: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
References: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
Message-ID: <z1xdLDskIEyA3q011eBSxgekT-50rPtRJsArT0bN56A=.e08883b3-238e-4764-a9f9-c7ffb0e058fa@github.com>

On Wed, 1 Oct 2025 22:29:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes the test which intermittently fails.
> 
> The test requests MethodEntry. SingleStep and Breakpoint events globally (from all threads).
> MethodEntry handler checks location (to be expected test method);
> Breakpoint request specifies location in the testes method, only test threads calls the method;
> SingleStep handler has no checks for thread or location. So once SingleStep event is enabled, event from other thread can be posted first (or several events from different threads).
> The fix enables SingleStep event only for test thread (we get it in MethodEntry)
> 
> testing: tier3

This is good. Thank you for fixing!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27598#pullrequestreview-3295126067

From vlivanov at openjdk.org  Thu Oct  2 20:52:48 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 2 Oct 2025 20:52:48 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9]
In-Reply-To: <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
Message-ID: <q_QBlS7zWYLUATRqIw96jh2OtHRLpQnl3ljR81vt_Wc=.90c55d9b-4723-499f-9680-1e1c928cf9ea@github.com>

On Fri, 26 Sep 2025 20:07:36 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java
>   
>   Co-authored-by: Manuel H?ssig <manuel at haessig.org>

Still looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27059#pullrequestreview-3296355729

From dlong at openjdk.org  Thu Oct  2 22:24:02 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 22:24:02 GMT
Subject: RFR: 8366461: Remove obsolete method handle invoke logic [v9]
In-Reply-To: <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
 <o-zjLKc9ZA1Lg5HAwhDKng89uuSG2qq2y4Yv4osYquU=.7b02295a-f873-4658-8273-383ee0572d8a@github.com>
Message-ID: <9wbYkH5F7FQqsuagYmsja5H-_YOZSel32FHZA0Ofet0=.e3faece6-0131-43e1-ae22-e9f50d81588f@github.com>

On Fri, 26 Sep 2025 20:07:36 GMT, Dean Long <dlong at openjdk.org> wrote:

>> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Frame.java
>   
>   Co-authored-by: Manuel H?ssig <manuel at haessig.org>

Thanks Vladimir for the re-review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27059#issuecomment-3363412878

From dlong at openjdk.org  Thu Oct  2 22:24:03 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Oct 2025 22:24:03 GMT
Subject: Integrated: 8366461: Remove obsolete method handle invoke logic
In-Reply-To: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
References: <LQQer6eHAvGEV6clizLClEdOtBBIO7GCQCzibGcEzL8=.7ec9480c-c660-460d-ab5c-69d4d4a4d03d@github.com>
Message-ID: <hOAlQx1s_BG3Q2sOvC_SXvaGZ5w68TCaInIuBmFIIQ4=.e99220e3-674c-4a59-9c69-621bfd441464@github.com>

On Tue, 2 Sep 2025 19:21:48 GMT, Dean Long <dlong at openjdk.org> wrote:

> At one time, JSR292 support needed special logic to save and restore SP across method handle instrinsic calls, but that is no longer the case. The only platform that still does the save/restore is arm32, which is no longer necessary. The save/restore can be removed along with related APIs and logic. Note that the arm32 port is largely based on the x86 port, which stopped doing the save/restore in jdk9 ([JDK-8068945](https://bugs.openjdk.org/browse/JDK-8068945)).

This pull request has now been integrated.

Changeset: da7121af
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da7121aff9eccb046b82a75093034f1cdbd9b9e4
Stats:     899 lines in 76 files changed: 22 ins; 825 del; 52 mod

8366461: Remove obsolete method handle invoke logic

Reviewed-by: vlivanov, mhaessig

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

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

From amenkov at openjdk.org  Thu Oct  2 23:42:54 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Oct 2025 23:42:54 GMT
Subject: RFR: 8304811:
 vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails
 with JVMTI_ERROR_TYPE_MISMATCH
In-Reply-To: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
References: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
Message-ID: <jiCj_Renw-hLKBXWcybKtY9MblwXRMSukuwFbaS7RV8=.a8cf932c-3058-43dd-839a-52cfc743b951@github.com>

On Wed, 1 Oct 2025 22:29:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes the test which intermittently fails.
> 
> The test requests MethodEntry. SingleStep and Breakpoint events globally (from all threads).
> MethodEntry handler checks location (to be expected test method);
> Breakpoint request specifies location in the testes method, only test threads calls the method;
> SingleStep handler has no checks for thread or location. So once SingleStep event is enabled, event from other thread can be posted first (or several events from different threads).
> The fix enables SingleStep event only for test thread (we get it in MethodEntry)
> 
> testing: tier3

Thank you for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/27598#issuecomment-3363623493

From amenkov at openjdk.org  Thu Oct  2 23:42:55 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 2 Oct 2025 23:42:55 GMT
Subject: Integrated: 8304811:
 vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails
 with JVMTI_ERROR_TYPE_MISMATCH
In-Reply-To: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
References: <JzNj8SXeOpkbED61npxA9yM6e3CVHEMC02f_qXNmb9E=.0853a92d-b7cf-472b-bda5-71f30a8ff1e6@github.com>
Message-ID: <U6z3_B1N0O1HndVySiXwXTBZ9EWvWfmL0SQDHkk4olw=.65858db9-a4bb-40e4-9beb-3878b1d1792d@github.com>

On Wed, 1 Oct 2025 22:29:28 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> The change fixes the test which intermittently fails.
> 
> The test requests MethodEntry. SingleStep and Breakpoint events globally (from all threads).
> MethodEntry handler checks location (to be expected test method);
> Breakpoint request specifies location in the testes method, only test threads calls the method;
> SingleStep handler has no checks for thread or location. So once SingleStep event is enabled, event from other thread can be posted first (or several events from different threads).
> The fix enables SingleStep event only for test thread (we get it in MethodEntry)
> 
> testing: tier3

This pull request has now been integrated.

Changeset: 854b384b
Author:    Alex Menkov <amenkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/854b384b120fa2af41adca3048070866fe3cafd4
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8304811: vmTestbase/vm/mlvm/indy/func/jvmti/stepBreakPopReturn/INDIFY_Test.java fails with JVMTI_ERROR_TYPE_MISMATCH

Reviewed-by: lmesnik, dholmes, sspitsyn

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

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

From duke at openjdk.org  Fri Oct  3 12:07:21 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Fri, 3 Oct 2025 12:07:21 GMT
Subject: RFR: 8020207: jconsole fails connecting over SSL using
 service:jmx:rmi://...jndi...
Message-ID: <zrRemP36pH7JxZPw7tk117ugwJ20KQPFDkOGjBoYTIE=.0be695f2-9190-4816-b276-59ddc3ec3bb6@github.com>

This is the fix for the https://bugs.openjdk.org/browse/JDK-8020207, JConsole fails connecting over SSL using a string with a JMXServiceURL.

The cause of the issue is a connection to the RMI registry. If the registry and agent use SSLSockets and JConsole is trying to connect to the agent using "service:jmx:rmi..." URL, ProxyClient of the JConsole does not attempt to use SSL for communication with the registry, it always tries to connect using not secured Socket.

I would suggest to parse the JMXServiceURL and check the SSL config for the RMI registry for one specific case:

-  the schema of the JMXServiceURL is "rmi"
-  the path of the JMXServiceURL is "/jndi/"
-  the schema of the RMI registry URI is "rmi"
-  the path of the RMI registry URI is "/jmxrmi".

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

Commit messages:
 - Allow connection to the RMI registry protected by SSL/TLS using the URL

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

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

From sherman at openjdk.org  Fri Oct  3 19:10:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:10:20 GMT
Subject: RFR: 8365675: Add String Unicode Case-Folding Support
Message-ID: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>

### Summary

Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.

Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:

**String.equalsIgnoreCase(String)**

- Unicode-aware, locale-independent.
- Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
- Limited: does not support 1:M mapping defined in Unicode case folding.

**Character.toLowerCase(int) / Character.toUpperCase(int)**

- Locale-independent, single code point only.
- No support for 1:M mappings.

**String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**

- Based on Unicode SpecialCasing.txt, supports 1:M mappings.
- Intended primarily for presentation/display, not structural case-insensitive matching.
- Requires full string conversion before comparison, which is less efficient and not intended for structural matching.

**1:M mapping example, U+00DF (?)**

- String.toUpperCase(Locale.ROOT, "?") ? "SS"
- Case folding produces "ss", matching Unicode caseless comparison rules.


jshell> "\u00df".equalsIgnoreCase("ss")
$22 ==> false

jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
$24 ==> true


### Motivation & Direction

Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

- Unicode-compliant **full** case folding.
- Simpler, stable and more efficient case-less matching without workarounds.
- Brings Java's string comparison handling in line with other programming languages/libraries.

This PR proposes to introduce the following comparison methods in `String` class

- boolean equalsFoldCase(String anotherString)
- int compareToFoldCase(String anotherString)
- Comparator<String> UNICODE_CASEFOLD_ORDER

These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.

*Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.

### The New API


   /**
     * Compares this {@code String} to another {@code String} for equality,
     * using <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")}
     * returns {@code true}, since the character {@code U+00DF} (sharp s) folds
     * to {@code "ss"}.
     * <p>
     * Case folding is locale-independent and language-neutral, unlike
     * locale-sensitive transformations such as {@link #toLowerCase()} or
     * {@link #toUpperCase()}. It is intended for caseless matching,
     * searching, and indexing.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #equalsIgnoreCase(String)}. It implements full case folding as
     * defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code equalsIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @param  anotherString
     *         The {@code String} to compare this {@code String} against
     *
     * @return  {@code true} if the given object is not {@code null} and represents
     *          the same sequence of characters as this string under Unicode case
     *          folding; {@code false} otherwise.
     *
     * @see     #compareToFoldCase(String)
     * @see     #equalsIgnoreCase(String)
     * @since   26
     */
    public boolean equalsFoldCase(String anotherString)

    /**
     * Compares two strings lexicographically using <em>Unicode case folding</em>.
     * This method returns an integer whose sign is that of calling {@code compareTo}
     * on the Unicode case folded version of the strings. Unicode Case folding
     * eliminates differences in case according to the Unicode Standard, using the
     * mappings defined in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * Case folding is a locale-independent, language-neutral form of case mapping,
     * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)},
     * which applies a simpler locale-insensitive uppercase mapping. This method
     * follows the Unicode <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> take locale into account, and may
     * produce results that differ from locale-sensitive ordering. Use
     * {@link java.text.Collator} for locale-sensitive comparison.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #compareToIgnoreCase(String)}. It implements the <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @param   str   the {@code String} to be compared.
     * @return  a negative integer, zero, or a positive integer as the specified
     *          String is greater than, equal to, or less than this String,
     *          ignoring case considerations by case folding.
     * @see     #equalsFoldCase(String)
     * @see     #compareToIgnoreCase(String)
     * @see     java.text.Collator
     * @since   26
     */
    public int compareToFoldCase(String str) 

    /**
     * A Comparator that orders {@code String} objects as by
     * {@link #compareToFoldCase(String) compareToFoldCase()}.
     *
     * @see     #compareToFoldCase(String)
     * @since   26
     */
    public static final Comparator<String> UNICODE_CASEFOLD_ORDER;



### Usage Examples

Sharp s (U+00DF) case-folds to "ss"


    "stra?e".equalsIgnoreCase("strasse");             // false
    "stra?e".compareToIgnoreCase("strasse");          // != 0
    "stra?e".equalsFoldCase("strasse");               // true



### Performance

The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing  compareToIgnoreCase().


Benchmark                                         Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.asciiGreekLower         avgt   15  20.195 ? 0.300  ns/op
StringCompareToIgnoreCase.asciiGreekLowerCF       avgt   15  11.051 ? 0.254  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLower    avgt   15   6.035 ? 0.047  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLowerCF  avgt   15  14.786 ? 0.382  ns/op
StringCompareToIgnoreCase.asciiLower              avgt   15  17.688 ? 1.396  ns/op
StringCompareToIgnoreCase.asciiLowerCF            avgt   15  44.552 ? 0.155  ns/op
StringCompareToIgnoreCase.asciiUpperLower         avgt   15  13.069 ? 0.487  ns/op
StringCompareToIgnoreCase.asciiUpperLowerCF       avgt   15  58.684 ? 0.274  ns/op
StringCompareToIgnoreCase.greekLower              avgt   15  20.642 ? 0.082  ns/op
StringCompareToIgnoreCase.greekLowerCF            avgt   15   7.255 ? 0.271  ns/op
StringCompareToIgnoreCase.greekUpperLower         avgt   15   5.737 ? 0.013  ns/op
StringCompareToIgnoreCase.greekUpperLowerCF       avgt   15  11.100 ? 1.147  ns/op
StringCompareToIgnoreCase.lower                   avgt   15  20.192 ? 0.044  ns/op
StringCompareToIgnoreCase.lowerrCF                avgt   15  11.257 ? 0.259  ns/op
StringCompareToIgnoreCase.supLower                avgt   15  54.801 ? 0.415  ns/op
StringCompareToIgnoreCase.supLowerCF              avgt   15  15.207 ? 0.418  ns/op
StringCompareToIgnoreCase.supUpperLower           avgt   15  14.431 ? 0.188  ns/op
StringCompareToIgnoreCase.supUpperLowerCF         avgt   15  19.149 ? 0.985  ns/op
StringCompareToIgnoreCase.upperLower              avgt   15   5.650 ? 0.051  ns/op
StringCompareToIgnoreCase.upperLowerCF            avgt   15  14.338 ? 0.352  ns/op
StringCompareToIgnoreCase.utf16SubLower           avgt   15  14.774 ? 0.200  ns/op
StringCompareToIgnoreCase.utf16SubLowerCF         avgt   15   2.669 ? 0.041  ns/op
StringCompareToIgnoreCase.utf16SupUpperLower      avgt   15  16.250 ? 0.099  ns/op
StringCompareToIgnoreCase.utf16SupUpperLowerCF    avgt   15  11.524 ? 0.327  ns/op



### Refs

[Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790)
[Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping)
[Unicode Technical Standard #18:  Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches)
[Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt)
[Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt)

### Other Languages

**Python string.casefold()**

The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons.

**Perl?s fc()**

Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings.
Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case.
Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. 

**ICU4J UCharacter.foldCase (Java)** 

Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF).
Method Signature (String based): public static String foldCase(String str, int options)
Method Signature (CharSequence & Appendable based): public static <A extends Appendable> A foldCase(CharSequence src, A dest, int options, Edits edits)
Key Features:
Case Folding: Converts a string to its case-folded equivalent.
Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings.
Context Insensitive: The mapping of a character is not affected by surrounding characters.
Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text.
Result Length: The resulting string can be longer or shorter than the original.
Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes.

**u_strFoldCase (C/C++)**

A lower-level C API function for case folding a string.
Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior.
Availability: Found in the ustring.h and unistr.h headers in the ICU4C library.

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

Commit messages:
 - 8365675: Add String Unicode Case-Folding Support

Changes: https://git.openjdk.org/jdk/pull/26892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365675
  Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892

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

From duke at openjdk.org  Sun Oct  5 13:00:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:00:44 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Move from j.l.management to com.sun.management etc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/ae29e031..64313101

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

  Stats: 345 lines in 13 files changed: 225 ins; 111 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

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

From duke at openjdk.org  Sun Oct  5 13:05:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:05:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <5dSkJW6Hrhm0M_3xFwlG4UwK1ITG2PvKhohIzQiDeA8=.cd29171f-1dae-486a-a525-beb13cb9ef2b@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

I introduced a JDK-specific MemoryMXBean in `com.sun.management` and added `getTotalGcCpuTime` there. I believe the Java idiomatic way to retrieve GC CPU time and process CPU time would be something like:


import java.lang.management.ManagementFactory;
import com.sun.management.MemoryMXBean;
import com.sun.management.OperatingSystemMXBean;

public class Main2 {
    public static void main(String[] args) {
        final MemoryMXBean mxMemoryBean = ManagementFactory.getPlatformMXBean(MemoryMXBean.class);
        final OperatingSystemMXBean mxOSBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);

        System.out.println("getTotalGcCpuTime: " + mxMemoryBean.getTotalGcCpuTime());
        System.out.println("getProcessCpuTime: " + mxOSBean.getProcessCpuTime());
    }
}


Given that `getTotalGcCpuTime` is most useful when you also sample process CPU time I like this symmetry, thanks for the suggestion.

I updated the language in the documentation:


    /**
     * Returns the CPU time used by garbage collection.
     *
     * <p> CPU time used by all garbage collection. In
     * general this includes time for all driver threads,
     * workers, VM operations on the VM thread and the string
     * deduplication thread (if enabled). May be non-zero even if no
     * GC cycle occurred. This method returns {@code -1} if the
     * platform does not support this operation or if called during
     * shutdown.
     *
     * @return the total accumulated CPU time for garbage collection
     * in nanoseconds.
     *
     * @since 26
     */


Since we include time om VM thread which strictly is not a garbage collection thread I think it is better to constrain it to "garbage collection" in general. Let me know what you think.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369043846

From duke at openjdk.org  Sun Oct  5 13:05:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:05:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
 <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
Message-ID: <4EoYAdS53Tor8IKojA3sXvzWPZOl7ENkvI7dvucgyj0=.12a455c1-03f7-490d-ac56-12e4fc63af19@github.com>

On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman
>> 
>>> The CSR is probably a bit premature ...
>> 
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
>> 
>>> Right now, the draft API spec makes it sounds very HotSpot VM specific.
>> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
>> 
>>> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.
>> 
>> Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).
>
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
> 
> I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 
> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
> 
> "genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.
> 
> I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.
> 
> One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

@AlanBateman if we agree on the new approach, I assume that a CSR would no longer be needed?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369044318

From ysuenaga at openjdk.org  Sun Oct  5 13:14:56 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 5 Oct 2025 13:14:56 GMT
Subject: RFR: 8245234: Still seeing missing mixed stack traces,
 even after JDK-8234624
Message-ID: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>

We haven't yet been able to unwind native frames in mixed mode jhsdb in some case even though we implement DWARF parser in [JDK-8234624](https://bugs.openjdk.org/browse/JDK-8234624). The cause is that `DwarfParser` would be reused.

DWARF is encoded as a state machine, so we have to initialize when we try to find new frame via DWARF. So I made change to create new `DwarfParser` instance everytime in `LinuxAMD64CFrame::sender`.

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

Commit messages:
 - 8245234: Still seeing missing mixed stack traces, even after JDK-8234624

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

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

From alanb at openjdk.org  Sun Oct  5 13:20:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 Oct 2025 13:20:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time
In-Reply-To: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
 <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
Message-ID: <XMa-r0ly3bAyMX-j6DVKHFSO2gSGgaOCt-d_9ppCCGs=.c2ebb81f-5072-4b79-9a1c-0652c8d987a3@github.com>

On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman
>> 
>>> The CSR is probably a bit premature ...
>> 
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
>> 
>>> Right now, the draft API spec makes it sounds very HotSpot VM specific.
>> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
>> 
>>> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.
>> 
>> Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).
>
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
> 
> I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 
> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
> 
> "genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.
> 
> I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.
> 
> One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

> @AlanBateman if we agree on the new approach, I assume that a CSR would no longer be needed?

A JDK-specific management interface is a supported/documented interface so additions/changes will need a CSR. I would suggest ignoring for the CSR for a few days to give time for feedback here on the updated proposal.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369053361

From jkern at openjdk.org  Mon Oct  6 09:52:54 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 6 Oct 2025 09:52:54 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v7]
In-Reply-To: <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
Message-ID: <A04kbCJL5HCmPM1eR5uDG83Xe14ATHv3L7Vujf-lei8=.d185560b-6dcd-4adb-b59f-d05087f3ac43@github.com>

On Thu, 25 Sep 2025 14:35:51 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update UnixOperatingSystem.c
>   
>   change sequence

Now code looks good two me.

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3303645119

From kevinw at openjdk.org  Mon Oct  6 10:53:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 6 Oct 2025 10:53:57 GMT
Subject: RFR: 8245234: Still seeing missing mixed stack traces,
 even after JDK-8234624
In-Reply-To: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
References: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
Message-ID: <VerSyySs1s6q-WEiJ2Rx75Gkx3lnakuK18PYtQJVyaI=.5cb4a7b6-f2a5-4c93-b462-85c0268efdd0@github.com>

On Sun, 5 Oct 2025 13:09:18 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We haven't yet been able to unwind native frames in mixed mode jhsdb in some case even though we implement DWARF parser in [JDK-8234624](https://bugs.openjdk.org/browse/JDK-8234624). The cause is that `DwarfParser` would be reused.
> 
> DWARF is encoded as a state machine, so we have to initialize when we try to find new frame via DWARF. So I made change to create new `DwarfParser` instance everytime in `LinuxAMD64CFrame::sender`.

I think this looks good, makes sense, the native DwarfParser has its own context.  So the existing reuse of dwarf as nextDwarf at old line 150 might be unwise!

I see that getNextCFA, called down at new line 168, handles nextDwarf being null.

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27636#pullrequestreview-3303845340

From mdoerr at openjdk.org  Mon Oct  6 11:04:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 11:04:53 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v7]
In-Reply-To: <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
Message-ID: <2onpGH0hXTL54MCYhiYFqL02uoTJXw4vQNLcBcI0ioA=.406b9108-dcea-420c-9770-d4c712640e59@github.com>

On Thu, 25 Sep 2025 14:35:51 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update UnixOperatingSystem.c
>   
>   change sequence

This looks good. Thanks for implementing it! A few minor nits.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 34:

> 32: #include <stdlib.h>
> 33: #include <libperfstat.h>
> 34: #include <pthread.h>

This is outside of hotspot, but I'd still sort includes (HotSpot style guide says "Keep the include lines sorted.").

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 36:

> 34: #include <pthread.h>
> 35: #include "com_sun_management_internal_OperatingSystemImpl.h"
> 36: #define HTIC2SEC(x) (((double)(x) * XINTFRAC) / 1000000000.0)

I'd prefer using `HTIC2NANOSEC(timebase_diff) / 1000000000.0` and removing this macro. It's only used at one place.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 91:

> 89:             load = 0.0;
> 90:         }
> 91:         else {

Coding style: We typically don't start a new line for `else`.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 128:

> 126:         counters.stats = curr_stats;
> 127:         counters.timebase = curr_timebase;
> 128:         if(delta_time == 0) {

Whitespace after `if`.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 130:

> 128:         if(delta_time == 0) {
> 129:             cpu_load = 0.0;
> 130:         }

Same here.

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

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3303835839
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405682597
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405699968
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405708424
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405710898
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405710177

From alanb at openjdk.org  Mon Oct  6 11:48:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Oct 2025 11:48:50 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

src/jdk.management/share/classes/com/sun/management/MemoryMXBean.java line 45:

> 43:      * GC cycle occurred. This method returns {@code -1} if the
> 44:      * platform does not support this operation or if called during
> 45:      * shutdown.

Now that the proposal is a JDK-specific management interface it means that this method can say something about how it relates to, or how it might be used with, OperatingSystemMXBean::getProcessCpuTime. 

I'm also wondering about ThreadMXBean::isThreadCpuTimeSupported. Is it possible for this to return false but getTotalGcCpuTime to return a value >= 0. The former concerns Java threads so it might not have any connection to this new method which concerns CPU usage by non-Java threads, but someone is bound to ask.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2405893440

From sroy at openjdk.org  Mon Oct  6 12:08:23 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 12:08:23 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v8]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'openjdk:master' into cpuprocessload
 - Update UnixOperatingSystem.c
   
   change sequence
 - Merge branch 'openjdk:master' into cpuprocessload
 - Thread safety,struct and perfInit()
 - Thread safety,struct and perfInit()
 - Update ProblemList.txt
 - Merge branch 'master' into cpuprocessload
 - Merge branch 'master' into cpuprocessload
 - Update UnixOperatingSystem.c
 - Merge branch 'openjdk:master' into cpuprocessload
 - ... and 4 more: https://git.openjdk.org/jdk/compare/2bfada3f...b31e68c9

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

Changes: https://git.openjdk.org/jdk/pull/25332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=07
  Stats: 100 lines in 2 files changed: 94 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

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

From duke at openjdk.org  Mon Oct  6 12:22:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 6 Oct 2025 12:22:48 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>
Message-ID: <JkqE79GvlPwCKJumq_ADRDzrm8poExa9abYAXgbcwWo=.e7d89796-16f1-49cb-8efa-694c6f859c59@github.com>

On Mon, 6 Oct 2025 11:46:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm also wondering about ThreadMXBean::isThreadCpuTimeSupported. Is it possible for this to return false but getTotalGcCpuTime to return a value >= 0.

`ThreadMXBean::isThreadCpuTimeSupported` uses the value from `os::is_thread_cpu_time_supported`:

https://github.com/openjdk/jdk/blob/6431310109a02ec5c34f877a1c690afb00193043/src/hotspot/share/services/management.cpp#L131-L137

I ensure to always return `-1` if thread cpu time is not supported as this is the contract that is promised by the documentation.

https://github.com/openjdk/jdk/blob/6431310109a02ec5c34f877a1c690afb00193043/src/hotspot/share/services/management.cpp#L894-L896

So, no this is not possible. However, `is_thread_cpu_time_enabled` is not being considered, but as you say, this method only concerns Java threads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2405993712

From mdoerr at openjdk.org  Mon Oct  6 12:30:57 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 12:30:57 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v8]
In-Reply-To: <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
Message-ID: <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>

On Mon, 6 Oct 2025 12:08:23 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>    
>    change sequence
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - Thread safety,struct and perfInit()
>  - Thread safety,struct and perfInit()
>  - Update ProblemList.txt
>  - Merge branch 'master' into cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2bfada3f...b31e68c9

Problem list needs an update, too. See error message above.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3371396115

From sroy at openjdk.org  Mon Oct  6 14:21:30 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 14:21:30 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v9]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/b31e68c9..18897e90

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

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

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

From sroy at openjdk.org  Mon Oct  6 14:21:32 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 14:21:32 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v8]
In-Reply-To: <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
 <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>
Message-ID: <LfO3Ro1Oipuvts4QRTviE-6vI3ywa7OSEgeHH1l3524=.6fa32de0-d920-4f79-928d-99cbcd04d12c@github.com>

On Mon, 6 Oct 2025 12:28:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Problem list needs an update, too. See error message above.

Hi Martin 
which error are you referring to ? I am unable to view any particular error message.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3371912370

From mdoerr at openjdk.org  Mon Oct  6 15:35:25 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 15:35:25 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v8]
In-Reply-To: <LfO3Ro1Oipuvts4QRTviE-6vI3ywa7OSEgeHH1l3524=.6fa32de0-d920-4f79-928d-99cbcd04d12c@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
 <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>
 <LfO3Ro1Oipuvts4QRTviE-6vI3ywa7OSEgeHH1l3524=.6fa32de0-d920-4f79-928d-99cbcd04d12c@github.com>
Message-ID: <XSI1PoLRusuwC95IMWXJHu1XbnTiN63oRog5jlrCuRw=.2ca43356-078c-4f87-a80d-bcb0fb2029de@github.com>

On Mon, 6 Oct 2025 14:16:00 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > Problem list needs an update, too. See error message above.
> 
> Hi Martin which error are you referring to ? I am unable to view any particular error message.

Error

 ?? 8030957 is used in problem lists: [test/jdk/ProblemList.txt]

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372328703

From mdoerr at openjdk.org  Mon Oct  6 15:39:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 15:39:29 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v9]
In-Reply-To: <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
Message-ID: <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>

On Mon, 6 Oct 2025 14:21:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

There is still "javax/management/MBeanServer/OldMBeanServerTest.java            8030957 aix-all". Does this test work as well, now?

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372347450

From mdoerr at openjdk.org  Mon Oct  6 15:43:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 15:43:20 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
Message-ID: <9CUh04oikviQyZw5O7Rx1FnQHmOVZKvL2Dfp5ZG3Beo=.3b3fc738-35c5-44c9-8193-a08c892140bf@github.com>

On Tue, 8 Jul 2025 13:16:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> If we only address minimum AIX 7.2 we can probably simplify this approach or even go away from the current dynamic loading approach. See also https://bugs.openjdk.org/browse/JDK-8222719 where I did already some cleanup (but kept the AIX 7.1 vs. 7.2 ) .

Dynamic loading was originally implemented for as400/PASE support. The support has never made it into OpenJDK. So, yes, that could be cleaned up.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372369557

From sroy at openjdk.org  Mon Oct  6 16:01:42 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 16:01:42 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v9]
In-Reply-To: <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
 <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>
Message-ID: <Eaiwo5UYja60gLAckWZnBqvJrfpqC18OD0bIjT1wpjU=.0901674d-6258-4f15-ab31-fdad8c9a5c0b@github.com>

On Mon, 6 Oct 2025 15:36:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> javax/management/MBeanServer/OldMBeanServerTest.java

The test is getting skipped. Do we use a different bug id ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372467771

From cjplummer at openjdk.org  Mon Oct  6 18:25:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 6 Oct 2025 18:25:35 GMT
Subject: RFR: 8245234: Still seeing missing mixed stack traces,
 even after JDK-8234624
In-Reply-To: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
References: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
Message-ID: <m4ttB689rnBi0BrQR1B6szwp-xH3w3_ryHTOz2au-Ow=.d472fd5e-fd06-4792-8add-6138febe11ea@github.com>

On Sun, 5 Oct 2025 13:09:18 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We haven't yet been able to unwind native frames in mixed mode jhsdb in some case even though we implement DWARF parser in [JDK-8234624](https://bugs.openjdk.org/browse/JDK-8234624). The cause is that `DwarfParser` would be reused.
> 
> DWARF is encoded as a state machine, so we have to initialize when we try to find new frame via DWARF. So I made change to create new `DwarfParser` instance everytime in `LinuxAMD64CFrame::sender`.

Looks good!

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27636#pullrequestreview-3306469550

From mdoerr at openjdk.org  Mon Oct  6 20:46:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 20:46:47 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v9]
In-Reply-To: <Eaiwo5UYja60gLAckWZnBqvJrfpqC18OD0bIjT1wpjU=.0901674d-6258-4f15-ab31-fdad8c9a5c0b@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
 <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>
 <Eaiwo5UYja60gLAckWZnBqvJrfpqC18OD0bIjT1wpjU=.0901674d-6258-4f15-ab31-fdad8c9a5c0b@github.com>
Message-ID: <R5didGqtb8kobJ3XBSZ1-Qk1mgeP_0sgrV_MsCMQHaU=.1e77b3ef-b0b9-44e5-b594-c587c90fe572@github.com>

On Mon, 6 Oct 2025 15:58:48 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > javax/management/MBeanServer/OldMBeanServerTest.java
> 
> The test is getting skipped. Do we use a different bug id ?

It's getting skipped because it's in the ProblemList. I think you can simply remove it from the ProblemList.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3374020707

From mbaesken at openjdk.org  Tue Oct  7 07:14:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Oct 2025 07:14:52 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v9]
In-Reply-To: <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
Message-ID: <Paco4omOj8wH8f5QqhCxA05iuR2Etgn5Y1Z_2_KcRP0=.e6f30b6b-6b6c-4f49-b6e5-79cfe8b71977@github.com>

On Mon, 6 Oct 2025 14:21:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks okay  to me; but please handle the problemlist too (was pointed out already).

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

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3308718969

From jsjolen at openjdk.org  Tue Oct  7 10:00:31 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Oct 2025 10:00:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v11]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Move BSMAttribute BSMAttributeEntries to own header file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/55f6d5bc..aed82e9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=09-10

  Stats: 385 lines in 8 files changed: 226 ins; 159 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27198/head:pull/27198

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

From sroy at openjdk.org  Tue Oct  7 10:41:26 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 7 Oct 2025 10:41:26 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v10]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

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

 - problem list
 - problem list
 - problem list

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/18897e90..432022f0

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

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

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

From dholmes at openjdk.org  Tue Oct  7 10:58:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 7 Oct 2025 10:58:48 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v11]
In-Reply-To: <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>
Message-ID: <srBEHJBB2_P_ADO3fCwO9jUJmW5KSnYpqs6FKEVwoww=.b8c793ba-f30b-48c9-8665-d9bf6f72c70a@github.com>

On Tue, 7 Oct 2025 10:00:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move BSMAttribute BSMAttributeEntries to own header file

src/hotspot/share/oops/bsmAttribute.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.

You need to preserve the initial copyright year from the files that originally contained the relocated code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2410226254

From mdoerr at openjdk.org  Tue Oct  7 10:59:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 7 Oct 2025 10:59:50 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v10]
In-Reply-To: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
Message-ID: <JganxtcqKhfDMQrlOpeWiQXEm6LIETnqHVLxZD7tTkQ=.73d8ba6c-36fe-49ac-9288-e275297dfe15@github.com>

On Tue, 7 Oct 2025 10:41:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - problem list
>  - problem list
>  - problem list

Thanks for the update!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3309573669

From ysuenaga at openjdk.org  Tue Oct  7 12:51:01 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Oct 2025 12:51:01 GMT
Subject: RFR: 8245234: Still seeing missing mixed stack traces,
 even after JDK-8234624
In-Reply-To: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
References: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
Message-ID: <MR7ph-4RiEGoiWkRgqxUk75nsh51w8TXhtregArgV8A=.d42bae60-b67a-4563-badf-0aa9297e6ac6@github.com>

On Sun, 5 Oct 2025 13:09:18 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We haven't yet been able to unwind native frames in mixed mode jhsdb in some case even though we implement DWARF parser in [JDK-8234624](https://bugs.openjdk.org/browse/JDK-8234624). The cause is that `DwarfParser` would be reused.
> 
> DWARF is encoded as a state machine, so we have to initialize when we try to find new frame via DWARF. So I made change to create new `DwarfParser` instance everytime in `LinuxAMD64CFrame::sender`.

Thanks both for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/27636#issuecomment-3376736581

From ysuenaga at openjdk.org  Tue Oct  7 12:51:02 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Oct 2025 12:51:02 GMT
Subject: Integrated: 8245234: Still seeing missing mixed stack traces,
 even after JDK-8234624
In-Reply-To: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
References: <6XykvEMtiEIFeu5IOBIcinG7pG4pC022tmcEIoLOC2I=.23a093ba-a480-45dc-b653-3eb333c58a0a@github.com>
Message-ID: <2Q-dQicYtTVTZSdPYuVg6ArWmOQvNggmqHgoe7jUnOU=.895db8be-fb66-4c24-bb73-d2bde2908532@github.com>

On Sun, 5 Oct 2025 13:09:18 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We haven't yet been able to unwind native frames in mixed mode jhsdb in some case even though we implement DWARF parser in [JDK-8234624](https://bugs.openjdk.org/browse/JDK-8234624). The cause is that `DwarfParser` would be reused.
> 
> DWARF is encoded as a state machine, so we have to initialize when we try to find new frame via DWARF. So I made change to create new `DwarfParser` instance everytime in `LinuxAMD64CFrame::sender`.

This pull request has now been integrated.

Changeset: 9c46febc
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9c46febcac01b9f1831f5f3e2a68dd1f1612a01f
Stats:     12 lines in 1 file changed: 0 ins; 5 del; 7 mod

8245234: Still seeing missing mixed stack traces, even after JDK-8234624

Reviewed-by: kevinw, cjplummer

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

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

From jsjolen at openjdk.org  Tue Oct  7 12:57:04 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 7 Oct 2025 12:57:04 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v11]
In-Reply-To: <srBEHJBB2_P_ADO3fCwO9jUJmW5KSnYpqs6FKEVwoww=.b8c793ba-f30b-48c9-8665-d9bf6f72c70a@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <HPcIFbb2rBqvDfb4b-oNBhiSrBjgsfpZd4L4oTMwhek=.99956e78-6d48-4006-9705-18e889801350@github.com>
 <srBEHJBB2_P_ADO3fCwO9jUJmW5KSnYpqs6FKEVwoww=.b8c793ba-f30b-48c9-8665-d9bf6f72c70a@github.com>
Message-ID: <PIjn0k_gZzVMUtq7jyCIrmMbLAB6zt8io0aMFAA4_gs=.710943ba-ed94-46f3-8872-d69b2d92f728@github.com>

On Tue, 7 Oct 2025 10:54:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move BSMAttribute BSMAttributeEntries to own header file
>
> src/hotspot/share/oops/bsmAttribute.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved.
> 
> You need to preserve the initial copyright year from the files that originally contained the relocated code.

I think all of the copied code is from 2025, but let's do the safe thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2410536152

From sroy at openjdk.org  Tue Oct  7 13:01:57 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 7 Oct 2025 13:01:57 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v8]
In-Reply-To: <A04kbCJL5HCmPM1eR5uDG83Xe14ATHv3L7Vujf-lei8=.d185560b-6dcd-4adb-b59f-d05087f3ac43@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
 <A04kbCJL5HCmPM1eR5uDG83Xe14ATHv3L7Vujf-lei8=.d185560b-6dcd-4adb-b59f-d05087f3ac43@github.com>
Message-ID: <0m2jzwhOjmO9U7RQkZ3YSeRiF4zzfbzQXtpIpamUrbQ=.c9f408b1-38fb-4a9d-bdc0-e241a907254f@github.com>

On Mon, 6 Oct 2025 09:49:46 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>    
>>    change sequence
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - Thread safety,struct and perfInit()
>>  - Thread safety,struct and perfInit()
>>  - Update ProblemList.txt
>>  - Merge branch 'master' into cpuprocessload
>>  - Merge branch 'master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2bfada3f...b31e68c9
>
> Now code looks good two me.

Hi @JoKern65 and @MBaesken  , can you approve the changes if all looks ok, since new commit removed the old approvals.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3376784925

From acobbs at openjdk.org  Tue Oct  7 20:03:25 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 7 Oct 2025 20:03:25 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v3]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <q_qI6DzbAbTICLbaW4FZkcey6WViuN-VizouO5n9oV0=.fb9b55bf-7717-4f77-b4de-de0473829edd@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 132 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Add clarifying comment.
 - Merge branch 'master' into JDK-8344159
 - Change inner class name to avoid shadowing superclass name.
 - Add a couple of code clarification comments.
 - Refactor test to avoid requiring changes to TestRunner.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - Add OPTIONS, PATH, and SUPPRESSION to the regression test.
 - ... and 122 more: https://git.openjdk.org/jdk/compare/910bb68e...3542625c

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=02
  Stats: 1659 lines in 34 files changed: 1486 ins; 49 del; 124 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

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

From duke at openjdk.org  Tue Oct  7 20:14:15 2025
From: duke at openjdk.org (Ivan Bereziuk)
Date: Tue, 7 Oct 2025 20:14:15 GMT
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <FR9QEZTX6k0npRCC3rYjUjRGOlxFez7pME9IRxzmp7Y=.dbc79198-11f4-45f5-ab78-3f34c0564d04@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <FR9QEZTX6k0npRCC3rYjUjRGOlxFez7pME9IRxzmp7Y=.dbc79198-11f4-45f5-ab78-3f34c0564d04@github.com>
Message-ID: <_h6iPBFZzttUFCxAiBm1h7CzQzzDtQboxBFEVO_Mj0o=.c17cc4f9-3279-4f8d-adb1-69b049146ce7@github.com>

On Wed, 24 Sep 2025 22:24:35 GMT, Larry Cable <duke at openjdk.org> wrote:

>      My proposal would entail
>      * adding a new standard option to jcmd
>      * somehow funneling that option to the JVM
>      * the option should be optional, so that:
>      * old jcmd still works with new JVMs (and produces legacy jcmd output)
>      * new jcmd still works with old JVMs (and produces legacy jcmd output)
>      How complex would this be? There are two approaches to this. You
>      can either create a new attach listener protocol (we already have
>      ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or,
>      you can expand the jcmd parsing (see |jcmd(AttachOperation* op,
>      attachStream* out)| in attachListener.cpp).
> 
>  ATTACH_API_V2 supports "options".
>  Client (jcmd) detects options supported by the target VM ("getversion
>  options" command) and can set option values in attach command request.
>  Currently the only supported option is "streaming" (it allows turn off
>  streaming output).
>  The option is needed only for tests and needs to work for all attach
>  tools (jcmd, jstack, etc.), so it can be set by specifying java
>  property launching attach tool (like |jcmd
>  -J-Djdk.attach.allowStreamingOutput=false PID command|)

Agreed. I will be working on the proposal. Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3360367314

From larry.cable at oracle.com  Tue Oct  7 20:58:05 2025
From: larry.cable at oracle.com (Laurence Cable)
Date: Tue, 7 Oct 2025 13:58:05 -0700
Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands
In-Reply-To: <_h6iPBFZzttUFCxAiBm1h7CzQzzDtQboxBFEVO_Mj0o=.c17cc4f9-3279-4f8d-adb1-69b049146ce7@github.com>
References: <jSDENXYD2FmHqOfREbXyfEwi_criHx7jK478jo0OdDg=.c9b64cce-37d2-474e-8c40-ccb5ca083fd3@github.com>
 <FR9QEZTX6k0npRCC3rYjUjRGOlxFez7pME9IRxzmp7Y=.dbc79198-11f4-45f5-ab78-3f34c0564d04@github.com>
 <_h6iPBFZzttUFCxAiBm1h7CzQzzDtQboxBFEVO_Mj0o=.c17cc4f9-3279-4f8d-adb1-69b049146ce7@github.com>
Message-ID: <f684fa72-0565-4e50-a6c0-807a47054859@oracle.com>

at some point (soon) we should also define a (common) JSON envelope 
(schema) for those jcmds that implement a JSON content variant...

IMO it should potentially include:

- jcmd "name"
- JVM version string
- JVM pid
- timestamp
- host "identity"
- content version #
- ...

all jcmds supporting JSON o/p should wrap their content in this std 
envelope ...

the motivation for this is that since emitting JSON is primarily 
intended to enable programmatic parsing of such content, having the content
be self describing is highly desirable, particularly in a cloud 
environment ...

- Larry

On 10/7/25 1:14 PM, Ivan Bereziuk wrote:
> On Wed, 24 Sep 2025 22:24:35 GMT, Larry Cable <duke at openjdk.org> wrote:
>
>>       My proposal would entail
>>       * adding a new standard option to jcmd
>>       * somehow funneling that option to the JVM
>>       * the option should be optional, so that:
>>       * old jcmd still works with new JVMs (and produces legacy jcmd output)
>>       * new jcmd still works with old JVMs (and produces legacy jcmd output)
>>       How complex would this be? There are two approaches to this. You
>>       can either create a new attach listener protocol (we already have
>>       ATTACH_API_V2 vs ATTACH_API_V1, so the precedence is there). Or,
>>       you can expand the jcmd parsing (see |jcmd(AttachOperation* op,
>>       attachStream* out)| in attachListener.cpp).
>>
>>   ATTACH_API_V2 supports "options".
>>   Client (jcmd) detects options supported by the target VM ("getversion
>>   options" command) and can set option values in attach command request.
>>   Currently the only supported option is "streaming" (it allows turn off
>>   streaming output).
>>   The option is needed only for tests and needs to work for all attach
>>   tools (jcmd, jstack, etc.), so it can be set by specifying java
>>   property launching attach tool (like |jcmd
>>   -J-Djdk.attach.allowStreamingOutput=false PID command|)
> Agreed. I will be working on the proposal. Thank you.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3360367314


From cjplummer at openjdk.org  Wed Oct  8 03:04:39 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Oct 2025 03:04:39 GMT
Subject: RFR: 8369230: com/sun/jdi/SimulResumerTest.java timed out
Message-ID: <pwiNvHjM-39m6hKNYzyvaTqHIWuiJxw1wZNNmZhJ1UY=.65c4aaa0-d3cc-462c-87a4-1959ae796f11@github.com>

The test needs a longer timeout due to the recent timeout factor change. Test runs pushing close to 2 minutes seem common on windows, although the failure reported in the CR is the only case I see of it taking more than 2 minutes (and just barely more). Because of this I think 180 seconds should be plenty.

I'd like to push this as a trivial change.

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

Commit messages:
 - longer timeout for test

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

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

From kbarrett at openjdk.org  Wed Oct  8 04:01:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 04:01:28 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the C++
 Standard Library
Message-ID: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>

Please review this change to the HotSpot Style Guide to suggest that C++
Standard Library components may be used, after appropriate vetting and
discussion, rather than just a blanket "no, don't use it" with a few very
narrow exceptions. It provides some guidance on that vetting process and
the criteria to use, along with usage patterns.

In particular, it proposes that Standard Library headers should not be
included directly, but instead through HotSpot-provided wrapper headers. This
gives us a place to document usage, provide workarounds for platform issues in
a single place, and so on.

Such wrapper headers are provided by this PR for <cstddef>, <limits>, and
<type_info>, along with updates to use them. I have a separate change for
<new> that I plan to propose later, under JDK-8369187. There will be
additional followups for other C compatibility headers besides <cstddef>.

This PR also cleans up some nomenclature issues around forbid vs exclude and
the like.

Testing: mach5 tier1-5, GHA sanity tests

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

Commit messages:
 - add wrapper for <type_traits>
 - add wrapper for <cstddef>
 - add wrapper for <limits>
 - style guide permits some standard library facilities

Changes: https://git.openjdk.org/jdk/pull/27601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27601&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369186
  Stats: 623 lines in 68 files changed: 383 ins; 134 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

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

From sspitsyn at openjdk.org  Wed Oct  8 06:48:06 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 06:48:06 GMT
Subject: RFR: 8369230: com/sun/jdi/SimulResumerTest.java timed out
In-Reply-To: <pwiNvHjM-39m6hKNYzyvaTqHIWuiJxw1wZNNmZhJ1UY=.65c4aaa0-d3cc-462c-87a4-1959ae796f11@github.com>
References: <pwiNvHjM-39m6hKNYzyvaTqHIWuiJxw1wZNNmZhJ1UY=.65c4aaa0-d3cc-462c-87a4-1959ae796f11@github.com>
Message-ID: <APY5fTr4bJ8kcbNgleF8ZFICUiupC_bHoy-3PNUsJIE=.a9774c1c-eddf-4c30-97ed-6aa09e283e4d@github.com>

On Wed, 8 Oct 2025 02:55:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test needs a longer timeout due to the recent timeout factor change. Test runs pushing close to 2 minutes seem common on windows, although the failure reported in the CR is the only case I see of it taking more than 2 minutes (and just barely more). Because of this I think 180 seconds should be plenty.
> 
> I'd like to push this as a trivial change.

Looks good and trivial.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27684#pullrequestreview-3313217110

From stefank at openjdk.org  Wed Oct  8 07:10:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 8 Oct 2025 07:10:05 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_info>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

doc/hotspot-style.md line 1658:

> 1656: to anonymous heterogeneous sequences.  In particular, a standard-layout
> 1657: class is preferred to a tuple.
> 1658: 

I gave this feedback offline, but I'll record it here as well. I think that the tuple section should go to the undecided section.

I understand the wish to go with named classes, and I often prefer that as well, but I also see that people often refrain from doing using them various reasons and instead use out-parameters or mix return values into one primitive. I don't want to fully close the door on this feature, and would like us to put this in the undecided (yes, still implicitly forbidden) section. To me that signals that we can at least experiment with it to see if it makes sense to sometimes use it (and if it does we can bring that back for discussion). Whereas outright forbidding it puts a stake in the ground and tells the story that we really shouldn't be looking at tuples. I think that's a too strong of a statement.

src/hotspot/share/utilities/tuple.hpp line 2:

> 1: /*
> 2: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.

So we have our own tuple ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2412807041
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2412811951

From jsjolen at openjdk.org  Wed Oct  8 07:43:01 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 8 Oct 2025 07:43:01 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/aed82e9c..bb3a014d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=10-11

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

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

From jkern at openjdk.org  Wed Oct  8 09:02:08 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 8 Oct 2025 09:02:08 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v10]
In-Reply-To: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
Message-ID: <QusPSE9PAYxX7YZbpRTDF52mEaxFEVkcHEry7SWzg-o=.7120d7ec-8033-4fa8-8869-1dd4121694a0@github.com>

On Tue, 7 Oct 2025 10:41:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - problem list
>  - problem list
>  - problem list

Still looks good to me

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3313790272

From duke at openjdk.org  Wed Oct  8 09:07:42 2025
From: duke at openjdk.org (duke)
Date: Wed, 8 Oct 2025 09:07:42 GMT
Subject: RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX [v10]
In-Reply-To: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
Message-ID: <cROUxy8luDkxUCfmUzJIhfAGx6Vy7eW196LsQLW2e_0=.4cfdf8ee-01b1-424b-9bfc-2afc8c18fc46@github.com>

On Tue, 7 Oct 2025 10:41:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - problem list
>  - problem list
>  - problem list

@suchismith1993 
Your change (at version 432022f07def54a54b47d0302ecfa5974e6b43e9) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3380542958

From sroy at openjdk.org  Wed Oct  8 09:18:47 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 8 Oct 2025 09:18:47 GMT
Subject: Integrated: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <hstUyHhx082Ex0PLKbP6K6LypisAZ0Jgn6Lx_2Oh6pU=.ae1f94a0-edf9-4143-ae74-52c095b9c4ae@github.com>

On Tue, 20 May 2025 15:32:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

This pull request has now been integrated.

Changeset: d45e65ba
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Varada M <varadam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d45e65bab45f78f9f378cdc53837fe33190b7801
Stats:     98 lines in 2 files changed: 91 ins; 3 del; 4 mod

8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX

Reviewed-by: jkern, mdoerr, mbaesken

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

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

From jwaters at openjdk.org  Wed Oct  8 12:00:13 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Oct 2025 12:00:13 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <x3n2kXZ29R-MEeTmcoDFdMCLQu6hjmp6OdN4mIVfQmA=.c23a80a3-941c-45f8-9d71-b2221ac1998c@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_info>`, along with updates to use them.

Did you mean type_traits?

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3381173911

From kbarrett at openjdk.org  Wed Oct  8 13:12:26 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 13:12:26 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <x3n2kXZ29R-MEeTmcoDFdMCLQu6hjmp6OdN4mIVfQmA=.c23a80a3-941c-45f8-9d71-b2221ac1998c@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <x3n2kXZ29R-MEeTmcoDFdMCLQu6hjmp6OdN4mIVfQmA=.c23a80a3-941c-45f8-9d71-b2221ac1998c@github.com>
Message-ID: <xWgQdxXIbiOaMamOA3VrUSOQrboSIXCvA6fq29bW0yk=.8772d6bf-8649-42be-9a3b-2ba185c67d60@github.com>

On Wed, 8 Oct 2025 11:56:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> > `<type_info>`, along with updates to use them.
> 
> Did you mean type_traits?

Oops! Yes. Fixing description...

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3381469837

From kbarrett at openjdk.org  Wed Oct  8 13:25:58 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 13:25:58 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
Message-ID: <HU4q6eykF79sMxppTLwTcw-sSAsZDostfB34nVJKTGQ=.006d0371-8f28-4878-9f51-19afe8ca25a7@github.com>

On Wed, 8 Oct 2025 07:07:21 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> src/hotspot/share/utilities/tuple.hpp line 2:
> 
>> 1: /*
>> 2: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> So we have our own tuple ...

We have our own baby partial tuple. What's there is more like a heterogeneous
array with compile-time indexing. It's used for one thing, and provides just
enough functionality for that use. I'm not entirely convinced it's the right
tool for the job, though I haven't taken the time to work out alternatives.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2413850653

From kbarrett at openjdk.org  Wed Oct  8 13:51:03 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 8 Oct 2025 13:51:03 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
Message-ID: <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>

On Wed, 8 Oct 2025 07:04:59 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> doc/hotspot-style.md line 1658:
> 
>> 1656: to anonymous heterogeneous sequences.  In particular, a standard-layout
>> 1657: class is preferred to a tuple.
>> 1658: 
> 
> I gave this feedback offline, but I'll record it here as well. I think that the tuple section should go to the undecided section.
> 
> I understand the wish to go with named classes, and I often prefer that as well, but I also see that people often refrain from doing using them various reasons and instead use out-parameters or mix return values into one primitive. I don't want to fully close the door on this feature, and would like us to put this in the undecided (yes, still implicitly forbidden) section. To me that signals that we can at least experiment with it to see if it makes sense to sometimes use it (and if it does we can bring that back for discussion). Whereas outright forbidding it puts a stake in the ground and tells the story that we really shouldn't be looking at tuples. I think that's a too strong of a statement.

I have a different take on the distinction between forbidden and undecided. I
think of forbidden features as being those where there are good arguments
against. Whereas I think of undecided as perhaps having wishy washy arguments
in either direction, or even not seriously thought about. But good arguments
against can be overcome by better arguments in favor.

But I can see how someone else might take that distinction differently.

I also admit to being somewhat biased against tuple in particular. I've seen
a few pretty terrible uses... one was even my fault!

So okay, I'll recategorize tuple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2413928370

From jrose at openjdk.org  Wed Oct  8 19:02:44 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 8 Oct 2025 19:02:44 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>

On Thu, 2 Oct 2025 07:11:51 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

I like where this is going.  Thanks for putting in the hard work to make it happen.

doc/hotspot-style.md line 629:

> 627: occur. The C++98/03 `std::allocator` class is too limited to support our
> 628: usage. But changes to the allocator concept in more recent Standards removed
> 629: some of the limitations, supporting statefull allocators. HotSpot may, in the

s/statefull/stateful/

doc/hotspot-style.md line 647:

> 645: using those names easier, since the qualifiers don't need to be included. But
> 646: there are reasons not to do that.
> 647: 

s/reasons/several reasons/ (to better tee up the following bullet list)

doc/hotspot-style.md line 651:

> 649:     headers may be included, adding to the list of names being used. Also,
> 650:     future versions of the Standard Library may add currently unknown names to
> 651:     the headers already being included.

Maybe mention the `assert` macro at the end of the bullet, if there is no other example of a previous name collision:

> ?already being included.  (We already have a conflict from the HotSpot `assert` macro, although in that case the `std::` prefix is not applicable.)

doc/hotspot-style.md line 1971:

> 1969: 
> 1970: * `<system_error>`
> 1971: 

To continue the roll of rationale,  for `chrono` etc., here are some suggestions which I am just pulling out of my back pocket:

"HotSpot has its own timing support APIs."
"Initializer lists are an advanced C++ API feature which have surprising interactions with other initialization syntaxes in use in HotSpot."
"HotSpot uses floating point numbers, which are more portable and have more predictable performance characteristics than rational arithmetic."
"HotSpot has its own mechanisms for managing errors."

src/hotspot/share/code/relocInfo.cpp line 29:

> 27: #include "code/nmethod.hpp"
> 28: #include "code/relocInfo.hpp"
> 29: #include "cppstdlib/type_traits.hpp"

(I really, really like this scheme of wrapper headers for std stuff.  Thanks Kim!)

src/hotspot/share/cppstdlib/cstddef.hpp line 34:

> 32: // * std::max_align_t, std::nullptr_t
> 33: // * size_t (preferred) and std::size_t
> 34: // * ptrdiff_t (preferred) and std::ptrdiff_t

Are we 100% sure that `size_t` and `ptrdiff_t` will always be the `std` versions, on all platforms?
If not, uses of `std::size_t` and `std::ptrdiff_t` might turn out to be portability problems.

?Should I worry that `std::size_t` and `size_t` might be different types on some weirdo platform??

Maybe we should do a static-assert that those two names refer to the same type.
Then we can prove that the `std::` prefix will never cause the meaning of `size_t` to shift, on any platform.
I'm being a little paranoid here about possible failure modes specifically for `size_t`,
specifically because `size_t` is so pervasive and sensitive to type bugs.

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

Changes requested by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3315881937
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414655528
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414658231
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414716232
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414719117
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414738762
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414746409

From jrose at openjdk.org  Wed Oct  8 19:02:45 2025
From: jrose at openjdk.org (John R Rose)
Date: Wed, 8 Oct 2025 19:02:45 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
 <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>
Message-ID: <WZnPF70M36SG11iLNeHGMPDJZFCWGMCX7FyKKL4tjCg=.ea44cdd2-269f-428e-a325-051e15ab71a5@github.com>

On Wed, 8 Oct 2025 13:48:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> doc/hotspot-style.md line 1658:
>> 
>>> 1656: to anonymous heterogeneous sequences.  In particular, a standard-layout
>>> 1657: class is preferred to a tuple.
>>> 1658: 
>> 
>> I gave this feedback offline, but I'll record it here as well. I think that the tuple section should go to the undecided section.
>> 
>> I understand the wish to go with named classes, and I often prefer that as well, but I also see that people often refrain from doing using them various reasons and instead use out-parameters or mix return values into one primitive. I don't want to fully close the door on this feature, and would like us to put this in the undecided (yes, still implicitly forbidden) section. To me that signals that we can at least experiment with it to see if it makes sense to sometimes use it (and if it does we can bring that back for discussion). Whereas outright forbidding it puts a stake in the ground and tells the story that we really shouldn't be looking at tuples. I think that's a too strong of a statement.
>
> I have a different take on the distinction between forbidden and undecided. I
> think of forbidden features as being those where there are good arguments
> against. Whereas I think of undecided as perhaps having wishy washy arguments
> in either direction, or even not seriously thought about. But good arguments
> against can be overcome by better arguments in favor.
> 
> But I can see how someone else might take that distinction differently.
> 
> I also admit to being somewhat biased against tuple in particular. I've seen
> a few pretty terrible uses... one was even my fault!
> 
> So okay, I'll recategorize tuple.

I'm OK with cracking the door open on tuple, but I have to say I do like API-specific names very much.  (And `fst`/`snd` or whatever are not API specific; they are tuple-specific!)  So the guidance that steers folks towards name-based techniques, instead of positional techniques, is still sound.

I even like out-args, personally, in cases where the out-arg is for a return value that is clearly secondary to the main return value.  Example:  Main value is boolean, and out-arg is some hint about why the main value is what it is, like a position.  The out-arg can also be optional if a null pointer is tolerated (explicitly documented as such, of course), which is useful when the out-arg costs extra to compute.  (A separate boolean arg is OK for such uses also, but null pointers are so darn useful as optionality sentinels!)  Note that our TRAPS/THREAD macro system can be viewed as a giant set of out-args.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414737272

From sspitsyn at openjdk.org  Wed Oct  8 20:17:27 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 20:17:27 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
 <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com>
Message-ID: <EvzHMyvWdTZrKA9JhZFZCuwQ-zR2zY6haj7iz2to2-k=.7666e0fb-94b0-45a9-9ddf-56d9bc8b8869@github.com>

On Fri, 19 Sep 2025 11:47:50 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?

It depends. And no, it is not always 'human' level (debuggers, etc). It is used by profilers as well especially via Instrumentation API. And yes, JVMTI is that it's less performance sensitive than the usual JVM. However, it'd be nice to improve its performance, not degrade. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3383072852

From sspitsyn at openjdk.org  Wed Oct  8 20:30:31 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 20:30:31 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <np8mKw3qDSuT-S_1viDlLak4nnMnMrwuUmB6pkQg_B8=.7796826e-53b4-4224-8e10-9592750f1dcf@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <kdEYMOROlXwODe3REiG9i5Oq0H8wkvfooQQsK0pd7Q8=.6c882a51-8e95-492b-8669-c4d157dbaf98@github.com>
 <np8mKw3qDSuT-S_1viDlLak4nnMnMrwuUmB6pkQg_B8=.7796826e-53b4-4224-8e10-9592750f1dcf@github.com>
Message-ID: <UdEhW7UANuwDJTqRrQ1yEITHW26u-TVX5G5LL9inQdc=.e921d84c-f2dd-4215-b7a6-754a13800edf@github.com>

On Thu, 25 Sep 2025 12:10:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.hpp line 116:
>> 
>>> 114:     return _argument_count;
>>> 115:   }
>>> 116:   int argument(int n) const {
>> 
>> Q: Why was the function name changed?
>
> I think `argument_index` sounds a bit misleading, "the nth argument" makes more sense imo. Yes, I introduced the original name :-).

Why do you think the `argument_index` sounds a bit misleading? It is a CP index, is not it?
In opposite, the name `argument` is confusing. I'm suggesting to restore the function name.
Additionally, it is not easy to review relatively big refactoring, so it makes sense to avoid unnecessary renaming if possible.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2414959885

From sspitsyn at openjdk.org  Wed Oct  8 20:36:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 20:36:25 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v7]
In-Reply-To: <kyvxF6Ha8z3b-U7Gl6pDr3c5NVzPD_zyrxaNN0BnGJ8=.d1d31984-8494-4164-9298-afae1d3c2bc3@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <uhxs-6_dBIaUJvxPxaBDZKXNeSVtS0apz916z9LDW_Y=.d60691b9-d118-486e-a8b7-b5ac778d9d82@github.com>
 <TEilMfBj4quy7wrgYjqc1TsFWE6EkBdpYIrN6wj5Gkc=.b808b3fc-fc87-4208-b853-bcd926925a32@github.com>
 <gyrTFFJtTkugm_YWnZQoh9JsTJkBRCn_O3sS1DnKNas=.40281507-d3ba-464d-9198-988ac614f11f@github.com>
 <ju_FTYh8VnnpzfIabA-d2eBiydCuMc6Oa9okVz6k55U=.f0911423-85ee-4db7-a8a2-17aa0a91a91f@github.com>
 <kyvxF6Ha8z3b-U7Gl6pDr3c5NVzPD_zyrxaNN0BnGJ8=.d1d31984-8494-4164-9298-afae1d3c2bc3@github.com>
Message-ID: <dbp7OplmRrOf546hnE6RCLyFexZSGq2ztrBzdNailDM=.ab4fd1d8-d3bd-4dd7-a34e-be72cb4b6c98@github.com>

On Fri, 26 Sep 2025 10:17:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Why not? This PR is introducing these two classes. It is better to do in a simplified form. :)
>
> It's only introducing the BSMAttributeEntries class, the other one is pre-existing. I don't want the PR to get stuck on whether or not to do a rename of something previously determined to be fine.

Okay then. I agree, it is not a good idea to rename pre-existing identifiers in this PR. But naming consistency is still important.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2414971254

From cjplummer at openjdk.org  Wed Oct  8 20:38:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Oct 2025 20:38:16 GMT
Subject: RFR: 8369230: com/sun/jdi/SimulResumerTest.java timed out
In-Reply-To: <pwiNvHjM-39m6hKNYzyvaTqHIWuiJxw1wZNNmZhJ1UY=.65c4aaa0-d3cc-462c-87a4-1959ae796f11@github.com>
References: <pwiNvHjM-39m6hKNYzyvaTqHIWuiJxw1wZNNmZhJ1UY=.65c4aaa0-d3cc-462c-87a4-1959ae796f11@github.com>
Message-ID: <K_GAErnt0j8F5N4OGC8AK8TXZGBKX9MPD41PtXhlhSw=.a06428f7-0f9f-49ea-8092-aab5ad46e294@github.com>

On Wed, 8 Oct 2025 02:55:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test needs a longer timeout due to the recent timeout factor change. Test runs pushing close to 2 minutes seem common on windows, although the failure reported in the CR is the only case I see of it taking more than 2 minutes (and just barely more). Because of this I think 180 seconds should be plenty.
> 
> I'd like to push this as a trivial change.

Thanks Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/27684#issuecomment-3383139624

From cjplummer at openjdk.org  Wed Oct  8 20:41:27 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Oct 2025 20:41:27 GMT
Subject: Integrated: 8369230: com/sun/jdi/SimulResumerTest.java timed out
In-Reply-To: <pwiNvHjM-39m6hKNYzyvaTqHIWuiJxw1wZNNmZhJ1UY=.65c4aaa0-d3cc-462c-87a4-1959ae796f11@github.com>
References: <pwiNvHjM-39m6hKNYzyvaTqHIWuiJxw1wZNNmZhJ1UY=.65c4aaa0-d3cc-462c-87a4-1959ae796f11@github.com>
Message-ID: <apYkp6szUFcw-PbtJnNoKw6VNBh45NHXNqB8Vy6KUb4=.0bace245-528f-4de1-af35-6a8beb37a87a@github.com>

On Wed, 8 Oct 2025 02:55:49 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> The test needs a longer timeout due to the recent timeout factor change. Test runs pushing close to 2 minutes seem common on windows, although the failure reported in the CR is the only case I see of it taking more than 2 minutes (and just barely more). Because of this I think 180 seconds should be plenty.
> 
> I'd like to push this as a trivial change.

This pull request has now been integrated.

Changeset: 1aa62dca
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1aa62dcafd9f11ff3cb191525437e10bb789d276
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8369230: com/sun/jdi/SimulResumerTest.java timed out

Reviewed-by: sspitsyn

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

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

From cjplummer at openjdk.org  Wed Oct  8 21:58:35 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Oct 2025 21:58:35 GMT
Subject: RFR: 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is
 broken and should be removed.
Message-ID: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>

Remove support for the debug agents USE_ITERATE_THROUGH_HEAP support, and the debugflags option used to enable it. Support has been broken for a very long time and can't possibly be relied on by anyone. Please see the CR for a full description.

Not there is a very small compatibility risk with removing the debugflags option (any script that uses it would break). But since it was only used in support of USE_ITERATE_THROUGH_HEAP, is not included in the docs, and is only included in the help output for debug builds, I think the risk is very low. If used, script failures are likely a good thing as it would call attention to the fact that the user is attempting to use functionality that doesn't (and hasn't) worked.

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

Commit messages:
 - Get rid of USE_ITERATE_THROUGH_HEAP support

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

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

From sspitsyn at openjdk.org  Wed Oct  8 22:25:15 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 8 Oct 2025 22:25:15 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
Message-ID: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>

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

>> Hi,
>> 
>> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
>> 
>> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
>> 
>> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
>> 
>> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
>> 
>> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.
>
> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix copyright

Changes requested by sspitsyn (Reviewer).

src/hotspot/share/classfile/classFileParser.cpp line 3342:

> 3340: 
> 3341:     BSMAttributeEntry* entry = iter.reserve_new_entry(bootstrap_method_ref, num_bootstrap_arguments);
> 3342:     guarantee_property(entry != nullptr, "Invalid BootstrapMethods num_bootstrap_methods. The total amount of space reserved for the BootstrapMethod attribute was not sufficient", CHECK);

Nit: This line is too big. It is a good idea to split the message. Also, would it better to move this guaranty for `nullptr` into the `reserve_new_entry()`?

src/hotspot/share/classfile/classFileParser.cpp line 3345:

> 3343: 
> 3344:     for (int argi = 0; argi < num_bootstrap_arguments; argi++) {
> 3345:       const u2 bootstrap_argument_index = cfs->get_u2_fast();

Nit: There is no need to rename `argument_index` to `bootstrap_argument_index`. It makes it harder to review. In this specific context it is clear that the argument index is a bootstrap method argument index.

src/hotspot/share/oops/bsmAttribute.hpp line 97:

> 95:     int _cur_offset;
> 96:     // Current unused offset into BSMAEs bsm-data array
> 97:     int _cur_array;

Nit: The declarations at lines 95, 97 will be more readable if comments above declarations trail declarations. The comment should not start with capital.

src/hotspot/share/oops/bsmAttribute.hpp line 120:

> 118:   Array<u2>* _bootstrap_methods;
> 119: 
> 120:   // Copy the first num_entries into iter

Nit: Dot is absent at the end of comment.

src/hotspot/share/oops/bsmAttribute.inline.hpp line 34:

> 32:       _cur_array + BSMAttributeEntry::u2s_required(argc) > insert_into->bootstrap_methods()->length()) {
> 33:     return nullptr;
> 34:   }

Nit: This check needs a comment. Also, I'd suggest to add a guarantee here instead of returning `nullptr`.

src/hotspot/share/oops/bsmAttribute.inline.hpp line 35:

> 33:     return nullptr;
> 34:   }
> 35:   insert_into->_offsets->at_put(_cur_offset, _cur_array);

Q: Can `insert_into->_offsets` be `nullptr` here? Should we add an assert?

src/hotspot/share/oops/constantPool.cpp line 1626:

> 1624: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
> 1625:                                  const constantPoolHandle& to_cp,
> 1626:                                  TRAPS) {

Nit: Indent is not right.

src/hotspot/share/oops/constantPool.hpp line 94:

> 92:   InstanceKlass*       _pool_holder; // the corresponding class
> 93: 
> 94:   BSMAttributeEntries _bsmaentries;

Nit: Suggestion to rename: `_bsmaentries` => `_bsm_entries`.

src/hotspot/share/oops/constantPool.inline.hpp line 90:

> 88:   return resolved_references()->obj_at(cache()->resolved_method_entry_at(index)->resolved_references_index());
> 89: }
> 90: 

Nit: Is this really needed?

src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 682:

> 680:   const int new_bs_i = _bsmae_iter.current_offset();
> 681:   BSMAttributeEntry* new_bsme =
> 682:     _bsmae_iter.reserve_new_entry(new_ref_i, old_bsme->argument_count());

Nit: There is not check for `new_bsme == nullptr`.

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

PR Review: https://git.openjdk.org/jdk/pull/27198#pullrequestreview-3316437973
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2414977385
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415001187
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415015413
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415020512
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415042398
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415048756
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415138981
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415149935
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415151472
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2415039223

From cjplummer at openjdk.org  Wed Oct  8 22:47:24 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 8 Oct 2025 22:47:24 GMT
Subject: RFR: 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is
 broken and should be removed [v2]
In-Reply-To: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>
References: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>
Message-ID: <Ap_l-vS9OOM98dJ-0uLeaiUlno5TMW7PHqdBFZTDQFo=.9dcaf940-b7fb-4ab2-87b0-07951a23573e@github.com>

> Remove support for the debug agents USE_ITERATE_THROUGH_HEAP support, and the debugflags option used to enable it. Support has been broken for a very long time and can't possibly be relied on by anyone. Please see the CR for a full description.
> 
> Note there is a very small compatibility risk with removing the debugflags option (any script that uses it would break). But since it was only used in support of USE_ITERATE_THROUGH_HEAP, is not included in the docs, and is only included in the help output for debug builds, I think the risk is very low. If used, script failures are likely a good thing as it would call attention to the fact that the user is attempting to use functionality that doesn't (and hasn't) worked.

Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:

  Get rid of no longer needed cbObjectTagInstance() function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27706/files
  - new: https://git.openjdk.org/jdk/pull/27706/files/94429a50..d6b0e5a2

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

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

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

From kbarrett at openjdk.org  Thu Oct  9 00:55:10 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 00:55:10 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
Message-ID: <0_An3HGn6Xd-zcB-53QaFn5tfq7u4CFIQAr1srQAjOY=.bf4127ac-a6c4-4c42-a9e4-ae24df62bfe3@github.com>

On Wed, 8 Oct 2025 18:12:44 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> doc/hotspot-style.md line 629:
> 
>> 627: occur. The C++98/03 `std::allocator` class is too limited to support our
>> 628: usage. But changes to the allocator concept in more recent Standards removed
>> 629: some of the limitations, supporting statefull allocators. HotSpot may, in the
> 
> s/statefull/stateful/

Fixed locally for next push.

> doc/hotspot-style.md line 647:
> 
>> 645: using those names easier, since the qualifiers don't need to be included. But
>> 646: there are reasons not to do that.
>> 647: 
> 
> s/reasons/several reasons/ (to better tee up the following bullet list)

Fixed locally for next push.

> doc/hotspot-style.md line 651:
> 
>> 649:     headers may be included, adding to the list of names being used. Also,
>> 650:     future versions of the Standard Library may add currently unknown names to
>> 651:     the headers already being included.
> 
> Maybe mention the `assert` macro at the end of the bullet, if there is no other example of a previous name collision:
> 
>> ?already being included.  (We already have a conflict from the HotSpot `assert` macro, although in that case the `std::` prefix is not applicable.)

There aren't any previous examples because we don't have any examples of doing
this thing that we're warning against (`using` a namespace).  `assert` is a
different problem, unrelated to namespaces. (Remember that one of the usual
knocks against macros is that they don't respect namespaces.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313253
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313425
PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415313670

From sspitsyn at openjdk.org  Thu Oct  9 02:13:09 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 9 Oct 2025 02:13:09 GMT
Subject: RFR: 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is
 broken and should be removed [v2]
In-Reply-To: <Ap_l-vS9OOM98dJ-0uLeaiUlno5TMW7PHqdBFZTDQFo=.9dcaf940-b7fb-4ab2-87b0-07951a23573e@github.com>
References: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>
 <Ap_l-vS9OOM98dJ-0uLeaiUlno5TMW7PHqdBFZTDQFo=.9dcaf940-b7fb-4ab2-87b0-07951a23573e@github.com>
Message-ID: <CC5UyZ78X4lZZe67IPn0eGDql582vi9BmfSXQ_YaBPc=.a40b7b70-3c60-499b-960a-83a6d4fff021@github.com>

On Wed, 8 Oct 2025 22:47:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Remove support for the debug agents USE_ITERATE_THROUGH_HEAP support, and the debugflags option used to enable it. Support has been broken for a very long time and can't possibly be relied on by anyone. Please see the CR for a full description.
>> 
>> Note there is a very small compatibility risk with removing the debugflags option (any script that uses it would break). But since it was only used in support of USE_ITERATE_THROUGH_HEAP, is not included in the docs, and is only included in the help output for debug builds, I think the risk is very low. If used, script failures are likely a good thing as it would call attention to the fact that the user is attempting to use functionality that doesn't (and hasn't) worked.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of no longer needed cbObjectTagInstance() function

Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27706#pullrequestreview-3316995903

From kbarrett at openjdk.org  Thu Oct  9 03:04:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 03:04:06 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
Message-ID: <Vy6_Av1foffAAxNdsFAKpuXyDeYWAimW0BUz-rLn13o=.2ca254f0-112c-4525-8277-c8ccbb5f8e06@github.com>

On Wed, 8 Oct 2025 18:40:01 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> doc/hotspot-style.md line 1971:
> 
>> 1969: 
>> 1970: * `<system_error>`
>> 1971: 
> 
> To continue the roll of rationale,  for `chrono` etc., here are some suggestions which I am just pulling out of my back pocket:
> 
> "HotSpot has its own timing support APIs."
> "Initializer lists are an advanced C++ API feature which have surprising interactions with other initialization syntaxes in use in HotSpot."
> "HotSpot uses floating point numbers, which are more portable and have more predictable performance characteristics than rational arithmetic."
> "HotSpot has its own mechanisms for managing errors."

I'll add some stuff to the PR change.

> "HotSpot has its own timing support APIs."

The argument for chrono is that our existing APIs aren't serving us well.
chrono provides strong type safety. We've had multiple cases of mistakes like
a double seconds being treated as double millis or vice versa, and other
similar errors. But it would be a large effort to adopt chrono. And we'd need
to decide whether to use the predefined clocks or hook up chrono to our
clocks. It may be that using the predefined clocks is fine, but it's a
question that needs careful study.

> "Initializer lists are an advanced C++ API feature which have surprising
> interactions with other initialization syntaxes in use in HotSpot."

I think the trailing "in use in HotSpot" can be dropped from that. Mostly I
think they are fine, but the potential ambiguity between some forms of direct
initialization and initializer list initialization, and the resolution of that
ambiguity, is unfortunate.

> "HotSpot uses floating point numbers ..."

Note that `<ratio>` is a *compile-time* rational arithmetic package. It's also
fixed (though parameterized) precision. It's not a general purpose rational
arithmetic facility. My understanding is that it started life as a detail of
chrono, and was extracted and promoted to a public facility in the belief that
it has broader utility.

> "HotSpot has its own mechanisms for managing errors."

Well, no, we don't really. Or rather, we've got a plethora of bespoke ad hoc
mechanisms. There's a bunch of discussion happening around that topic lately.
I don't think we've coalesced around any particular approach yet. And even
once we decided on something it's likely to take quite a while for rollout to
really make use of whatever we settle on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415447980

From kbarrett at openjdk.org  Thu Oct  9 03:37:05 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 03:37:05 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library
In-Reply-To: <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
Message-ID: <7WSKAc7KY9uAmaHcNeZoYVFqQ-0Ekq16_W4-BonyR1I=.5b14e9f6-cce5-4993-8d03-a382044b5806@github.com>

On Wed, 8 Oct 2025 18:52:20 GMT, John R Rose <jrose at openjdk.org> wrote:

> Are we 100% sure ...

Yes.

> Should I worry ...

No.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2340r0.html
Clarifying the status of the "C headers"

On the basis of that paper, C++23 undeprecated the C headers (they'd been
deprecated since C++98) and gave them their own section in the main body of
the standard, rather than being relegated to an appendix.

The guidance is that a C++ source file should only include C headers if the
file also needs to be valid C source. I'm planning to nudge us in that
direction, except by using our own wrapper headers, like cppstdlib/cstddef.hpp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2415481626

From kbarrett at openjdk.org  Thu Oct  9 04:07:02 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 04:07:02 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - jrose comments
 - move tuple to undecided category

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27601/files
  - new: https://git.openjdk.org/jdk/pull/27601/files/98e7ccbb..c886ec36

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

  Stats: 78 lines in 2 files changed: 55 ins; 8 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

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

From kbarrett at openjdk.org  Thu Oct  9 08:40:32 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 08:40:32 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <HU4q6eykF79sMxppTLwTcw-sSAsZDostfB34nVJKTGQ=.006d0371-8f28-4878-9f51-19afe8ca25a7@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
 <HU4q6eykF79sMxppTLwTcw-sSAsZDostfB34nVJKTGQ=.006d0371-8f28-4878-9f51-19afe8ca25a7@github.com>
Message-ID: <W9GSUFyS3jp9I3nMSOOtzUGAdhrdYixTqSa0ticwJBs=.0a3cbc0e-3ee0-4538-af6e-8927c5c5e691@github.com>

On Wed, 8 Oct 2025 13:23:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/tuple.hpp line 2:
>> 
>>> 1: /*
>>> 2: * Copyright (c) 2023, 2025, Oracle and/or its affiliates. All rights reserved.
>> 
>> So we have our own tuple ...
>
> We have our own baby partial tuple. What's there is more like a heterogeneous
> array with compile-time indexing. It's used for one thing, and provides just
> enough functionality for that use. I'm not entirely convinced it's the right
> tool for the job, though I haven't taken the time to work out alternatives.

I looked at the use of Tuple<...>. I think using named structs with named
members would be an improvement. Eliminates questions like is src element 0
and dst element 1, or is it the other way around.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2416001474

From stefank at openjdk.org  Thu Oct  9 09:15:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 9 Oct 2025 09:15:33 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
Message-ID: <4uDJA25Pz-Sxiy9kAtbOnUDSqe9h7b47d5AFYDv_ipQ=.e7d5060f-5261-4d77-8a9c-bfb75cdbbea8@github.com>

On Thu, 9 Oct 2025 04:07:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - jrose comments
>  - move tuple to undecided category

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3317964481

From duke at openjdk.org  Thu Oct  9 11:08:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 9 Oct 2025 11:08:04 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <oXzhqZKUqdw8fRdoRBOAZ74YGC2pZ0SX7UgqaPGz94g=.10b90d7e-ff79-42fc-9f89-b6a77f8f0490@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Thanks all for your suggestions. I have updated the CSR to align with the discussion in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3385342335

From fweimer at openjdk.org  Thu Oct  9 11:30:19 2025
From: fweimer at openjdk.org (Florian Weimer)
Date: Thu, 9 Oct 2025 11:30:19 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
Message-ID: <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>

On Thu, 9 Oct 2025 04:07:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - jrose comments
>  - move tuple to undecided category

doc/hotspot-style.md line 567:

> 565: 
> 566: Functions that may throw exceptions must not be used.  This is in accordance
> 567: with the HotSpot policy of [not using exceptions](#error-handling).

In the GCC implementation, destructor registration may throw `__gnu_cxx::recursive_init_error` (via the `__cxa_guard_acquire` Itanium ABI function). Are global or static objects with non-trivial destructors permitted? I think there are a couple of such uses today.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2416467456

From kbarrett at openjdk.org  Thu Oct  9 12:18:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 9 Oct 2025 12:18:38 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
 <NtEUnStxuGM09AJUdDeq9D_jOOZcUqwQo7c5xA7S01Q=.81e51825-71b3-4fca-82f3-3baecd537ba0@github.com>
Message-ID: <6u0Ia6A2xQnv51Ti0Jchg6rnncfRRvtK5oGS963CeIA=.bc9c1481-60ad-443d-923b-dc86277dbb14@github.com>

On Thu, 9 Oct 2025 11:27:26 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - jrose comments
>>  - move tuple to undecided category
>
> doc/hotspot-style.md line 567:
> 
>> 565: 
>> 566: Functions that may throw exceptions must not be used.  This is in accordance
>> 567: with the HotSpot policy of [not using exceptions](#error-handling).
> 
> In the GCC implementation, destructor registration may throw `__gnu_cxx::recursive_init_error` (via the `__cxa_guard_acquire` Itanium ABI function). Are global or static objects with non-trivial destructors permitted? I think there are a couple of such uses today.

We (you and me, @fweimer-rh) discussed this a couple of years ago:
https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/082324.html

Quoting from here:
https://mail.openjdk.org/pipermail/hotspot-dev/2023-December/083142.html

"
Empirically, a recursive initialization attempt doesn't make any attempt to
throw. Rather, it blocks forever waiting for a futex signal from a thread that
succeeds in the initialization. Which of course will never come.

And that makes sense, now that I've looked at the code.

In __cxa_guard_acquire, with _GLIBCXX_USE_FUTEX, if the guard indicates
initialization hasn't yet been completed, then it goes into a while loop.
This while loop tries to claim initialization.  Failing that, it checks
whether initialization is complete.  Failing that, it does a SYS_futex
syscall, waiting for some other thread to perform the initialization.  There's
nothing there to check for recursion.

throw_recursive_init_exception is only called if single-threaded (either by
configuration or at runtime).
"

It doesn't look like there have been any relevant changes in that area since
then. So I think there is still not a problem here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2416593903

From kevinw at openjdk.org  Thu Oct  9 14:02:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Oct 2025 14:02:33 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Questions that this change brings up to me:

Is there a general understanding or a statement of what it means to be standard or JDK-specific in this area?
If previous JSRs which specified JMX independently were the spec, and are these days part of the JDK Platform, what does it mean to be standard or JDK-specific?

How do we make it easy for somebody to add useful features in the right place...

Particularly on this method about GC time, I don't really follow the reasoning for not accepting the method in java.lang.MemoryMXBean.

The most generic Java API can admit that Java is Garbage-Collected, and that doing that work can take some CPU time.

The originally proposed JavaDoc had some HotSpot-specific terms in it, which maybe did not fit.  But they could still be valid if rephrased as a note of examples of the kinds of things that an implementation may need to do.

I'm wondering if the com.sun.management... interfaces made sense as a way to add features outside of an original JSR spec.  Maybe that was their intent.  But are we still in that world, do we still need to do that?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3386013198

From amenkov at openjdk.org  Thu Oct  9 19:25:56 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 9 Oct 2025 19:25:56 GMT
Subject: RFR: 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is
 broken and should be removed [v2]
In-Reply-To: <Ap_l-vS9OOM98dJ-0uLeaiUlno5TMW7PHqdBFZTDQFo=.9dcaf940-b7fb-4ab2-87b0-07951a23573e@github.com>
References: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>
 <Ap_l-vS9OOM98dJ-0uLeaiUlno5TMW7PHqdBFZTDQFo=.9dcaf940-b7fb-4ab2-87b0-07951a23573e@github.com>
Message-ID: <LX6gI8ELH8Me-wJiUVEeodpwjJSJhZnrkRgc7TknLwY=.bd82dbea-bf99-4574-8daa-f851c2d56713@github.com>

On Wed, 8 Oct 2025 22:47:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Remove support for the debug agents USE_ITERATE_THROUGH_HEAP support, and the debugflags option used to enable it. Support has been broken for a very long time and can't possibly be relied on by anyone. Please see the CR for a full description.
>> 
>> Note there is a very small compatibility risk with removing the debugflags option (any script that uses it would break). But since it was only used in support of USE_ITERATE_THROUGH_HEAP, is not included in the docs, and is only included in the help output for debug builds, I think the risk is very low. If used, script failures are likely a good thing as it would call attention to the fact that the user is attempting to use functionality that doesn't (and hasn't) worked.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of no longer needed cbObjectTagInstance() function

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27706#pullrequestreview-3320346750

From ysuenaga at openjdk.org  Thu Oct  9 23:34:20 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Oct 2025 23:34:20 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub on
 Linux AMD64
Message-ID: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>

I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:


sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
        at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)


And also I got following (strange) stacks which causes `AssersionFailure` in above:


----------------- 70094 -----------------
"ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007f8f64658462 __syscall_cancel_arch + 0x32
0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
0x00007f8f646a8c37 __GI___nanosleep + 0x17
0x00007f8f646bb14e __sleep + 0x3e
0x00007f8f4b3a8e1e <nep_invoker_blob>
0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c050800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame)
0x00007f8f4b33fe48 * jdk.internal.foreign.abi.DowncallStub+0x000000000c048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame)
0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c04e400.invoke(java.lang.Object, int) bci:44 (Interpreted frame)
0x00007f8f4b33fd00 * java.lang.invoke.LambdaForm$MH+0x000000000c04c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame)
0x00007f8f4b33fd00 * Test.run() bci:21 line:28 (Interpreted frame)
0x00007f8f4b33e098 <StubRoutines (continuation stubs)>
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b340206 <interpreter> return entry points
0x00007f8f4b33fe9a <interpreter> return entry points
0x00007f8f4b33fe9a <interpreter> return entry points
0x00007f8f4b33fe48 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b33fd00 <interpreter> return entry points
0x00007f8f4b3386fd <StubRoutines (initial stubs)>
0x00007f8f62bc0a7e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007f8f62bc11b3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007f8f62bc17bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007f8f62d83a90 thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007f8f62c02806 JavaThread::thread_main_inner() + 0x256
0x00007f8f63865b57 Thread::call_run() + 0xb7
0x00007f8f632fc588 thread_native_entry(Thread*) + 0x128
0x00007f8f6464ff54 start_thread + 0x2e4


According to stack layout described in continuationFreezeThaw.cpp and stub implementation in `StubGenerator::generate_cont_thaw()` in stubGenerator_x86_64.cpp, we cannot calculate caller SP from `CodeBlob` for continuation stub. We need to restore SP from `_cont_entry` in `JavaThread`.

After this fix, we can see following stacks:


----------------- 39371 -----------------
"ForkJoinPool-1-worker-1" #27 daemon prio=5 tid=0x00007fe83036f230 nid=39371 runnable [0x00007fe815e06000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007fe839b17462      __syscall_cancel_arch + 0x32
0x00007fe839b0b75c      __internal_syscall_cancel + 0x5c
0x00007fe839b67c37      __GI___nanosleep + 0x17
0x00007fe839b7a14e      __sleep + 0x3e
0x00007fe81f3a859e      <nep_invoker_blob>
0x00007fe81f33fe48      * java.lang.invoke.LambdaForm$MH+0x0000000041047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
0x00007fe81f33fe48      * java.lang.invoke.LambdaForm$MH+0x0000000041051400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame)
0x00007fe81f33fe48      * jdk.internal.foreign.abi.DowncallStub+0x0000000041048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x00007fe81f33fe48      * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame)
0x00007fe81f33fe48      * java.lang.invoke.LambdaForm$MH+0x000000004104e800.invoke(java.lang.Object, int) bci:44 (Interpreted frame)
0x00007fe81f33fd00      * java.lang.invoke.LambdaForm$MH+0x000000004104d800.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame)
0x00007fe81f33fd00      * Test.run() bci:21 line:28 (Interpreted frame)
0x00007fe81f33e098      <StubRoutines (continuation stubs)>
0x00007fe81f33fd00      * jdk.internal.vm.Continuation.run() bci:122 line:248 (Interpreted frame)
0x00007fe81f33fd00      * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Interpreted frame)
0x00007fe81f33fd00      * java.lang.VirtualThread$$Lambda+0x0000000041029b58.run() bci:4 (Interpreted frame)
0x00007fe81f340206      * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:4 line:1753 (Interpreted frame)
0x00007fe81f33fe9a      * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:1 line:1745 (Interpreted frame)
0x00007fe81f33fe9a      * java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() bci:51 line:1662 (Interpreted frame)
0x00007fe81f33fe48      * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Interpreted frame)
0x00007fe81f33fd00      * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Interpreted frame)
0x00007fe81f33fd00      * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Interpreted frame)
0x00007fe81f33fd00      * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Interpreted frame)
0x00007fe81f3386fd      <StubRoutines (initial stubs)>
0x00007fe837fc0a7e      JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007fe837fc11b3      JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007fe837fc17bb      JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007fe838183a90      thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007fe838002806      JavaThread::thread_main_inner() + 0x256
0x00007fe838c65b57      Thread::call_run() + 0xb7
0x00007fe8386fc588      thread_native_entry(Thread*) + 0x128
0x00007fe839b0ef54      start_thread + 0x2e4


I saw this issue on Linux AMD64. I'm not sure but it might happen on another platforms.

I haven't yet created a complete reproducer, but Test.java on JBS can be reproduced with high probability.

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

Commit messages:
 - 8369505: jhsdb jstack --mixed cannot handle continuation stub on Linux AMD64

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

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

From dholmes at openjdk.org  Fri Oct 10 05:46:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 10 Oct 2025 05:46:05 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <RzvNDs3MU7CxI1bwwSnSFOo43IP8RoqP7JOXC1HhV3U=.383c21d9-9a5d-490c-b9fb-8c5aa670041f@github.com>
Message-ID: <iNjD85NyiIAqTYuNqPtymJturfgclyWfnzZNq0QiVxc=.8efe3a56-5d65-4806-895f-430f1a422632@github.com>

On Thu, 9 Oct 2025 04:07:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - jrose comments
>  - move tuple to undecided category

> Are global or static objects with non-trivial destructors permitted? I think there are a couple of such uses today.

It is discouraged but yes they exist and cause problems. I am currently fixing a bunch of issues due to static Semaphore instances. https://bugs.openjdk.org/browse/JDK-8361462

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3388368328

From sspitsyn at openjdk.org  Fri Oct 10 06:03:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 06:03:07 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
Message-ID: <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>

On Thu, 9 Oct 2025 17:45:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition.

Thank you, Patrico!
I agree with this. Below is the patch for this change.


diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp
index 077b3fec505..fa6ede86cd9 100644
--- a/src/hotspot/share/prims/jvmtiExport.cpp
+++ b/src/hotspot/share/prims/jvmtiExport.cpp
@@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) {
   if (!can_post_frame_pop()) {
     return false;
   }
-  JvmtiThreadState *state = get_jvmti_thread_state(thread);
+  JvmtiThreadState *state = thread->jvmti_thread_state();
   if (state == nullptr) {
     return false;
   }
@@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati
   }
 
   assert(thread == JavaThread::current(), "must be");
-  JvmtiThreadState *state = get_jvmti_thread_state(thread);
+  JvmtiThreadState *state = thread->jvmti_thread_state();
   if (state == nullptr) {
     return;
   }


> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too?

Good idea. I was also thinking about it at some point.

> Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case.

I can be but could you be more presize about the preempt case? What place do you mean?

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388398133

From aboldtch at openjdk.org  Fri Oct 10 06:29:40 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 06:29:40 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v2]
In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
Message-ID: <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>

> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
> 
> Example stack trace:
> 
> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
> 
> 
> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.

Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:

 - sspitsyn patch
 - Revert "8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state"
   
   This reverts commit e133d9b73125ea907111a2a869ed824aca9bfa3d.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27716/files
  - new: https://git.openjdk.org/jdk/pull/27716/files/e133d9b7..4ec7ce98

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

  Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27716.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27716/head:pull/27716

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

From aboldtch at openjdk.org  Fri Oct 10 06:35:01 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 06:35:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
Message-ID: <Iv_JXTJ3IrRfxUfjYBzxzB9NkT7mpHgDrHyd0P-gf-c=.8b64b59f-39fa-472f-96c5-56438e2c2abe@github.com>

On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> I agree with this. Below is the patch for this change.

Done. 

I was also wondering why the original patch change from just `JavaThread::jvmti_thread_state` to `get_jvmti_thread_state`. But it looked so intentional, I thought it was fundamental to JDK-8368159.

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388474246

From sspitsyn at openjdk.org  Fri Oct 10 08:42:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 08:42:10 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
Message-ID: <KWxDHUJ-sUX_vyeRTySG1-WY_H8ZCGILuP3j6UTne2o=.3310163f-6aac-40ed-8f3e-a0723cd5f515@github.com>

On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> I think `JvmtiExport::has_frame_pops` should just check if `thread->jvmti_thread_state()` is nullptr?and return false, and not try to create the state. Same with `JvmtiExport::continuation_yield_cleanup()`. This `JvmtiExport::get_jvmti_thread_state()` method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the `JvmtiThreadState` created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in `VTMS_unmount_begin` so we would leave the wrong state in the platform thread until the next transition.
>> 
>> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a `!cont.entry()->is_virtual_thread()` check too?
>
>> I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition.
> 
> Thank you, Patrico!
> I agree with this. Below is the patch for this change.
> 
> 
> diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp
> index 077b3fec505..fa6ede86cd9 100644
> --- a/src/hotspot/share/prims/jvmtiExport.cpp
> +++ b/src/hotspot/share/prims/jvmtiExport.cpp
> @@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) {
>    if (!can_post_frame_pop()) {
>      return false;
>    }
> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>    if (state == nullptr) {
>      return false;
>    }
> @@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati
>    }
>  
>    assert(thread == JavaThread::current(), "must be");
> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>    if (state == nullptr) {
>      return;
>    }
> 
> 
>> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too?
> 
> Good idea. I was also thinking about it at some point.
> 
>> Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case.
> 
> I can be but could you be more presize about the preempt case? What place do you mean?

> /author @sspitsyn

This suggestion came from Patricio. :)

> I was also wondering why the original patch change from just JavaThread::jvmti_thread_state to get_jvmti_thread_state. But it looked so intentional, I thought it was fundamental to JDK-8368159.

Wrong assumptions. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3388899792

From sspitsyn at openjdk.org  Fri Oct 10 10:25:53 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 10:25:53 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <KWxDHUJ-sUX_vyeRTySG1-WY_H8ZCGILuP3j6UTne2o=.3310163f-6aac-40ed-8f3e-a0723cd5f515@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <KWxDHUJ-sUX_vyeRTySG1-WY_H8ZCGILuP3j6UTne2o=.3310163f-6aac-40ed-8f3e-a0723cd5f515@github.com>
Message-ID: <0O2-w0R94vfTJjRk7iVnL2EBImcfgmYNLHpI-gXEHlQ=.7937917d-80d9-493c-ab42-747001694da9@github.com>

On Fri, 10 Oct 2025 08:39:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>> I think JvmtiExport::has_frame_pops should just check if thread->jvmti_thread_state() is nullptr and return false, and not try to create the state. Same with JvmtiExport::continuation_yield_cleanup(). This JvmtiExport::get_jvmti_thread_state() method was added in 8312174 but I don?t think we want it for this case in freeze. Not only because no state should imply no frame pop requests, but also because it seems the JvmtiThreadState created and set to the platform thread will be for the vthread instance, but the rebind operation has already been executed in VTMS_unmount_begin so we would leave the wrong state in the platform thread until the next transition.
>> 
>> Thank you, Patrico!
>> I agree with this. Below is the patch for this change.
>> 
>> 
>> diff --git a/src/hotspot/share/prims/jvmtiExport.cpp b/src/hotspot/share/prims/jvmtiExport.cpp
>> index 077b3fec505..fa6ede86cd9 100644
>> --- a/src/hotspot/share/prims/jvmtiExport.cpp
>> +++ b/src/hotspot/share/prims/jvmtiExport.cpp
>> @@ -1694,7 +1694,7 @@ bool JvmtiExport::has_frame_pops(JavaThread* thread) {
>>    if (!can_post_frame_pop()) {
>>      return false;
>>    }
>> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
>> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>>    if (state == nullptr) {
>>      return false;
>>    }
>> @@ -1713,7 +1713,7 @@ void JvmtiExport::continuation_yield_cleanup(JavaThread* thread, jint continuati
>>    }
>>  
>>    assert(thread == JavaThread::current(), "must be");
>> -  JvmtiThreadState *state = get_jvmti_thread_state(thread);
>> +  JvmtiThreadState *state = thread->jvmti_thread_state();
>>    if (state == nullptr) {
>>      return;
>>    }
>> 
>> 
>>> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too?
>> 
>> Good idea. I was also thinking about it at some point.
>> 
>>> Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case.
>> 
>> I can be but could you be more presize about the preempt case? What place do you mean?
>
>> /author @sspitsyn
> 
> This suggestion came from Patricio. :)
> 
>> I was also wondering why the original patch change from just JavaThread::jvmti_thread_state to get_jvmti_thread_state. But it looked so intentional, I thought it was fundamental to JDK-8368159.
> 
> Wrong assumptions. :) For consistency with `JvmtiExport::continuation_yield_cleanup()`.

> @sspitsyn IIUC this cleanup of the frame_pop requests should only be needed for the plain continuation case, so shouldn?t we have a !cont.entry()->is_virtual_thread() check too?

This is one more suggestion from Patricio (I'm testing it now):


diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
index 33b4f2bf488..3e509e71551 100644
--- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
+++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
@@ -1626,7 +1626,7 @@ static void invalidate_jvmti_stack(JavaThread* thread) {
 }
 
 static void jvmti_yield_cleanup(JavaThread* thread, ContinuationWrapper& cont) {
-  if (JvmtiExport::has_frame_pops(thread)) {
+  if (!cont.entry()->is_virtual_thread() && JvmtiExport::has_frame_pops(thread)) {
     int num_frames = num_java_frames(cont);
 
     ContinuationWrapper::SafepointOp so(Thread::current(), cont);

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3389242915

From pchilanomate at openjdk.org  Fri Oct 10 14:56:15 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Oct 2025 14:56:15 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
Message-ID: <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>

On Fri, 10 Oct 2025 06:00:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Also, pre-existing and maybe for a different bug, but seems we are missing a call to invalidate_jvmti_stack() for the preempt case.
> 
> I can be but could you be more presize about the preempt case? What place do you mean?
>
So after freezing for the preempt case we should also call `invalidate_jvmti_stack()` in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug.

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3390600355

From pchilanomate at openjdk.org  Fri Oct 10 15:22:58 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Oct 2025 15:22:58 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <KV3vA_rbl2-FGlLztVczcQz9RrwjW1vVH9vESEetVBA=.4017fdb7-2e28-4e85-9496-879e4400becc@github.com>

On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

I can reproduce it with the attached test too. The issue happens when the return pc of the sender frame is the return barrier, which will be the case if the virtual thread was unmounted at some earlier point and there are still frames freezed in the stackChunk (see `frame::sender_for_interpreter_frame` and `frame::sender_for_compiled_frame` for handling this case in the VM). In your test, unmounting can happen at the `System.out.println` call.
So this issue will be present in the other platforms too. I tested the fix for x64 and looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3390733064

From jrose at openjdk.org  Fri Oct 10 17:17:03 2025
From: jrose at openjdk.org (John R Rose)
Date: Fri, 10 Oct 2025 17:17:03 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v2]
In-Reply-To: <Vy6_Av1foffAAxNdsFAKpuXyDeYWAimW0BUz-rLn13o=.2ca254f0-112c-4525-8277-c8ccbb5f8e06@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <zO_2pZ3oS3J4CHOxYs5LDvp_K55oyduA4H4g7e-quAI=.642d0aa9-a45a-4256-a0c2-f8625cc27654@github.com>
 <Vy6_Av1foffAAxNdsFAKpuXyDeYWAimW0BUz-rLn13o=.2ca254f0-112c-4525-8277-c8ccbb5f8e06@github.com>
Message-ID: <gmdQSCJtjoJ92QORY-Xi2_fFllRqpmQvmmEwCeMhZaM=.ee8c9f5d-485b-48f9-ae9c-e5e4112284c9@github.com>

On Thu, 9 Oct 2025 03:01:03 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> doc/hotspot-style.md line 1971:
>> 
>>> 1969: 
>>> 1970: * `<system_error>`
>>> 1971: 
>> 
>> To continue the roll of rationale,  for `chrono` etc., here are some suggestions which I am just pulling out of my back pocket:
>> 
>> "HotSpot has its own timing support APIs."
>> "Initializer lists are an advanced C++ API feature which have surprising interactions with other initialization syntaxes in use in HotSpot."
>> "HotSpot uses floating point numbers, which are more portable and have more predictable performance characteristics than rational arithmetic."
>> "HotSpot has its own mechanisms for managing errors."
>
> I'll add some stuff to the PR change.
> 
>> "HotSpot has its own timing support APIs."
> 
> The argument for chrono is that our existing APIs aren't serving us well.
> chrono provides strong type safety. We've had multiple cases of mistakes like
> a double seconds being treated as double millis or vice versa, and other
> similar errors. But it would be a large effort to adopt chrono. And we'd need
> to decide whether to use the predefined clocks or hook up chrono to our
> clocks. It may be that using the predefined clocks is fine, but it's a
> question that needs careful study.
> 
>> "Initializer lists are an advanced C++ API feature which have surprising
>> interactions with other initialization syntaxes in use in HotSpot."
> 
> I think the trailing "in use in HotSpot" can be dropped from that. Mostly I
> think they are fine, but the potential ambiguity between some forms of direct
> initialization and initializer list initialization, and the resolution of that
> ambiguity, is unfortunate.
> 
>> "HotSpot uses floating point numbers ..."
> 
> Note that `<ratio>` is a *compile-time* rational arithmetic package. It's also
> fixed (though parameterized) precision. It's not a general purpose rational
> arithmetic facility. My understanding is that it started life as a detail of
> chrono, and was extracted and promoted to a public facility in the belief that
> it has broader utility.
> 
>> "HotSpot has its own mechanisms for managing errors."
> 
> Well, no, we don't really. Or rather, we've got a plethora of bespoke ad hoc
> mechanisms. There's a bunch of discussion happening around that topic lately.
> I don't think we've coalesced around any particular approach yet. And even
> once we decided on something it's likely to take quite a while for rollout to
> really make use of whatever we settle on.

I love a good nerd sniping! Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2421306579

From cjplummer at openjdk.org  Fri Oct 10 19:27:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Oct 2025 19:27:09 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <KZXXEr75p1tFw_VybUrFWBDQLkviS1uFDgWUaWiVEwA=.4bcdb55a-957a-4288-ad55-f01fd2bf165b@github.com>

On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

I'm seeing a similar exception on macosx-aarch64 with your test, however, I don't see all the frames that you are seeing. The stack dump stops at `Test.run()`.

Also, on threads that are fully dumped, the output is different than you working dump above. I'm not sure if this is expected:


"ForkJoinPool-1-worker-6" #33 daemon prio=5 tid=0x0000000147856810 nid=41731 runnable [0x0000000172df5000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
 - java.lang.invoke.LambdaForm$MH+0x0000000801047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x0000000801054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
 - jdk.internal.foreign.abi.DowncallStub+0x0000000801048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000000080104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000000080104e000.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
 - Test.run() @bci=21, line=28 (Interpreted frame)
 - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1487 (Interpreted frame)
 - java.lang.VirtualThread.run(java.lang.Runnable) @bci=62, line=456 (Interpreted frame)
 - java.lang.VirtualThread$VThreadContinuation$1.run() @bci=15, line=248 (Interpreted frame)
 - jdk.internal.vm.Continuation.enter0() @bci=4, line=322 (Interpreted frame)
 - jdk.internal.vm.Continuation.enter(jdk.internal.vm.Continuation, boolean) @bci=1, line=313 (Interpreted frame)
 - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
 - jdk.internal.vm.Continuation.run() @bci=122, line=248 (Interpreted frame)
 - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
 - java.lang.VirtualThread$$Lambda+0x0000000801027670.run() @bci=4 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=364, line=2019 (Interpreted frame)
 - java.util.concurrent.ForkJoinWorkerThread.run() @bci=31, line=187 (Interpreted frame)

I can see if your changes are applicable to aarch64. If they work, then great, if not, I'll probably need some help getting it right.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3391989222
PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3391996631

From cjplummer at openjdk.org  Fri Oct 10 19:31:01 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Oct 2025 19:31:01 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <h36A29lU7Opzh6qm8LasFQZt_iN5aj7LScirAU0-JXc=.bbca5da6-f45c-4755-bdb3-64e765610b83@github.com>

On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Can you convert your test to JTREG? It would make it a lot easier to test fixes on all platforms. Also, the fix is a bit fragile and it would be nice to quickly detect if it breaks again in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392014129

From sspitsyn at openjdk.org  Fri Oct 10 19:51:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 19:51:05 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
Message-ID: <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>

On Fri, 10 Oct 2025 14:53:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> So after freezing for the preempt case we should also call invalidate_jvmti_stack() in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug.

We have `jvmti_yield_cleanup()` call in the `freeze_epilog()` which is called from the `preempt_epilog()`. The `jvmti_yield_cleanup()` has a call to `invalidate_jvmti_stack()`. Do I miss anything?

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392113146

From cjplummer at openjdk.org  Fri Oct 10 19:55:01 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 10 Oct 2025 19:55:01 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>

On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.

"ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
 - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
 - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
 - Test.run() @bci=21, line=28 (Interpreted frame)
 - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
 - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame)
 - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
 - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=364, line=2019 (Interpreted frame)
 - java.util.concurrent.ForkJoinWorkerThread.run() @bci=31, line=187 (Interpreted frame)

"ForkJoinPool-1-worker-6" #36 daemon prio=5 tid=0x0000000159052610 nid=42243 runnable [0x000000017296d000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
 - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
 - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000003fe01050400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
 - Test.run() @bci=21, line=28 (Interpreted frame)
 - java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) @bci=5, line=1487 (Interpreted frame)
 - java.lang.VirtualThread.run(java.lang.Runnable) @bci=62, line=456 (Interpreted frame)
 - java.lang.VirtualThread$VThreadContinuation$1.run() @bci=15, line=248 (Interpreted frame)
 - jdk.internal.vm.Continuation.enter0() @bci=4, line=322 (Interpreted frame)
 - jdk.internal.vm.Continuation.enter(jdk.internal.vm.Continuation, boolean) @bci=1, line=313 (Interpreted frame)
 - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
 - jdk.internal.vm.Continuation.run() @bci=122, line=248 (Interpreted frame)
 - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
 - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
 - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
 - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) @bci=364, line=2019 (Interpreted frame)
 - java.util.concurrent.ForkJoinWorkerThread.run() @bci=31, line=187 (Interpreted frame)

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392130193

From ayang at openjdk.org  Fri Oct 10 20:02:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 20:02:01 GMT
Subject: RFR: 8369574: Remove
 javax/management/remote/mandatory/connection/BrokenConnectionTest.java from
 ProblemList-Virtual.txt
In-Reply-To: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
References: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
Message-ID: <fliguDS_eTZiTBhRgJQhRRUsyl3FLgUscf_waadc9Uk=.2c6b6726-b68b-43a6-93bf-b24ac504ab22@github.com>

On Fri, 10 Oct 2025 15:51:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted (JDK-8307369) like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now.  Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27747#pullrequestreview-3325753324

From pchilanomate at openjdk.org  Fri Oct 10 20:37:02 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Oct 2025 20:37:02 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
 <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
Message-ID: <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>

On Fri, 10 Oct 2025 19:48:47 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > So after freezing for the preempt case we should also call invalidate_jvmti_stack() in case there are FramePop requests in the carrier. I?m guessing we don?t have tests for this. But we could address it in a separate bug.
> 
> We have `jvmti_yield_cleanup()` call in the `freeze_epilog()` which is called from the `preempt_epilog()`. The `jvmti_yield_cleanup()` has a call to `invalidate_jvmti_stack()`. Do I miss anything?
>
Yes, but we are calling the other overload of `freeze_epilog()` which only logs and verifies the continuation. : )

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392242151

From pchilanomate at openjdk.org  Fri Oct 10 20:41:00 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 10 Oct 2025 20:41:00 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
Message-ID: <GRgx2q_VzV4EYyfw53ws1Csp7UowrcriX3uAnZabOVM=.5621e1e8-3ca0-4647-b223-9908ad1faf1d@github.com>

On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
>
These two different stack traces are expected and depend on whether the vthread was unmounted or not. With the current test this is timing dependent. You can run the test commenting out the `System.out.println` call, and then again replacing it with `Thread.yield()`. The string `<StubRoutines (continuation stubs)>` does look like from a previous version though. Even on x64 I see the `enterSpecial` frame printed out, and it matches what I would expect based on the patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392251835

From sspitsyn at openjdk.org  Fri Oct 10 22:33:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 10 Oct 2025 22:33:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
 <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
 <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>
Message-ID: <VBJ6p35zrvNFjI5-stHYmJz5ux3-136ZlPnhIX6EJ2Y=.1def8864-c2e2-4dfc-93b3-2c06dd08b828@github.com>

On Fri, 10 Oct 2025 20:34:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Yes, but we are calling the other overload of freeze_epilog() which only logs and verifies the continuation. : )

I see, thanks! Do I understand it right that there is no need to call the `jvmti_yield_cleanup()` in this case? Does the preempt_epilog() is called for pure continuations as well?

I've filed new JVMTI bug:
[8369609](https://bugs.openjdk.org/browse/JDK-8369609) Continuations preempt_epilog is missing a call to invalidate_jvmti_stack

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3392488763

From ysuenaga at openjdk.org  Sat Oct 11 02:45:04 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 11 Oct 2025 02:45:04 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
Message-ID: <CtbT7tdmTw9277JudQDgAMfDkbBb3V6hjR8hlh5O7Io=.9da388b6-9169-4732-8d58-5013a1c6160b@github.com>

On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
> 
> "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
>  - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
>  - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
>  - Test.run() @bci=21, line=28 (Interpreted frame)
>  - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
>  - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame)
>  - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
>  - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
>  - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
>  - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.F...

@plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least).

Thanks @pchilano for explaining the problem, I understood it relates to unmount, it is triggered by `System.out.println` and we can replace it to `Thread.yield`. I can convert Test.java to JTREG test of course, However I'm not sure how we can reproduce this issue 100%. I guess the problem is very similar with race-condition - dependent on timing. Do you have any idea to happen the problem exactly?

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392807014

From ysuenaga at openjdk.org  Sat Oct 11 03:16:03 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 11 Oct 2025 03:16:03 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <34sQ54VukmkIdGeSWUrfO_wNuBXsBn4c13dNjqCyUsA=.119a9ecd-04a9-415b-8e77-c83e7c8b5506@github.com>

On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

I saw same issue in JDK 25 on Fedora Rawhide on Raspberry Pi 4.
I will try to fix on AArch64.


Server compiler detected.
JVM version is 25+36-3489
sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
        at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.senderForCompiledFrame(AARCH64Frame.java:414)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.aarch64.AARCH64Frame.sender(AARCH64Frame.java:295)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:207)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:212)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)



----------------- 1884 -----------------
"ForkJoinPool-1-worker-4" #30 daemon prio=5 tid=0x0000ffff982c0ce0 nid=1884 runnable [0x0000ffff4d20b000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x0000ffffa03282e8      __syscall_cancel_arch + 0x28
0x0000ffffa0358b7c      __clock_nanosleep + 0x3c
0x0000ffffa0363740      __GI___nanosleep + 0x20
0x0000ffffa0373f50      __sleep + 0x50
0x0000ffff87c4c878      <nep_invoker_blob>
0x0000ffff87b3b910      * java.lang.invoke.LambdaForm$MH+0x0000004001047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
0x0000ffff87b3b910      * java.lang.invoke.LambdaForm$MH+0x000000400104fc00.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame)
0x0000ffff87b3b910      * jdk.internal.foreign.abi.DowncallStub+0x0000004001048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x0000ffff87b3b910      * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame)
0x0000ffff87b3b910      * java.lang.invoke.LambdaForm$MH+0x000000400104dc00.invoke(java.lang.Object, int) bci:44 (Interpreted frame)
0x0000ffff87b3ba90      * java.lang.invoke.LambdaForm$MH+0x000000400104c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame)
0x0000ffff87b3ba90      * Test.run() bci:21 line:28 (Interpreted frame)
0x0000ffff87b3a080      <StubRoutines (continuationstubs)>
0x0000ffff87b3ba90      <interpreter> return entry points
0x0000ffff87b3ba90      <interpreter> return entry points
0x0000ffff87b3ba90      <interpreter> return entry points
0x0000ffff87b3c030      <interpreter> return entry points
0x0000ffff87b3b820      <interpreter> return entry points
0x0000ffff87b3b820      <interpreter> return entry points
0x0000ffff87b3b910      <interpreter> return entry points
0x0000ffff87b3ba90      <interpreter> return entry points
0x0000ffff87b3ba90      <interpreter> return entry points
0x0000ffff87b3ba90      <interpreter> return entry points
0x0000ffff87b37154      <StubRoutines (initialstubs)>
0x0000ffff9f620198      JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x248
0x0000ffff9f621824      JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0x174
0x0000ffff9f6fa7f8      thread_entry(JavaThread*, JavaThread*) + 0x8c
0x0000ffff9f639d88      JavaThread::thread_main_inner() [clone .part.0] + 0xa4
0x0000ffff9fbbc308      Thread::call_run() + 0xa8
0x0000ffff9fa006a8      thread_native_entry(Thread*) + 0xd8
0x0000ffffa031e8d4      start_thread + 0x404

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392845921

From ysuenaga at openjdk.org  Sat Oct 11 03:24:46 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 11 Oct 2025 03:24:46 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64 [v2]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <Sg0jgFP2e1AMMaY8hOHa6x4xl1pHMt0QEwxCAqNRgWc=.7bd58812-1412-438d-bf24-a902356b6965@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix trivial bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/32b75fc7..d2a80f56

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

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

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

From cjplummer at openjdk.org  Sat Oct 11 05:12:06 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Sat, 11 Oct 2025 05:12:06 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux AMD64
In-Reply-To: <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
Message-ID: <invP6sQ5jfAy9_oncbxq9ZZNVzHLNJRe8hcyMwCy1E8=.637df4ab-3eed-41f6-af61-595b1af93be8@github.com>

On Fri, 10 Oct 2025 19:52:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
> 
> "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
>  - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
>  - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
>  - Test.run() @bci=21, line=28 (Interpreted frame)
>  - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
>  - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame)
>  - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
>  - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
>  - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
>  - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
>  - java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.F...

> @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least).

I did not, and unfortunately --mixed is not support on OSX.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3392919979

From kevinw at openjdk.org  Sat Oct 11 11:52:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Sat, 11 Oct 2025 11:52:01 GMT
Subject: RFR: 8020207: jconsole fails connecting over SSL using
 service:jmx:rmi://...jndi...
In-Reply-To: <zrRemP36pH7JxZPw7tk117ugwJ20KQPFDkOGjBoYTIE=.0be695f2-9190-4816-b276-59ddc3ec3bb6@github.com>
References: <zrRemP36pH7JxZPw7tk117ugwJ20KQPFDkOGjBoYTIE=.0be695f2-9190-4816-b276-59ddc3ec3bb6@github.com>
Message-ID: <MxG4tsCJG-WeZ74vxz9drKv5gYhllswZot3qu8U0DlU=.09f14b24-160f-4456-a34a-63b3d1747b3c@github.com>

On Fri, 3 Oct 2025 12:00:13 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> This is the fix for the https://bugs.openjdk.org/browse/JDK-8020207, JConsole fails connecting over SSL using a string with a JMXServiceURL.
> 
> The cause of the issue is a connection to the RMI registry. If the registry and agent use SSLSockets and JConsole is trying to connect to the agent using "service:jmx:rmi..." URL, ProxyClient of the JConsole does not attempt to use SSL for communication with the registry, it always tries to connect using not secured Socket.
> 
> I would suggest to parse the JMXServiceURL and check the SSL config for the RMI registry for one specific case:
> 
> -  the schema of the JMXServiceURL is "rmi"
> -  the path of the JMXServiceURL is "/jndi/"
> -  the schema of the RMI registry URI is "rmi"
> -  the path of the RMI registry URI is "/jmxrmi".

Yes I think this looks good.

Thanks for confirming in the JBS issue that the SSL connections work if using host/port, but fail when giving the URL (I expect all connections, not just SSL).
Makes sense as in the other constructor above this change, we set registryHostname and registryPort from the details of the target.
It's good to have this work both ways!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27622#pullrequestreview-3327015070

From ysuenaga at openjdk.org  Sat Oct 11 13:57:41 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 11 Oct 2025 13:57:41 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux [v3]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <nmX3XCz0n3I65SWssPIz3d2KED69SyBWNrqujwJ_shw=.42cbcd54-17f5-429a-ae68-59156758a233@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix for AArch64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/d2a80f56..2f3eee62

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

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

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

From ysuenaga at openjdk.org  Sat Oct 11 13:57:41 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 11 Oct 2025 13:57:41 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux [v2]
In-Reply-To: <Sg0jgFP2e1AMMaY8hOHa6x4xl1pHMt0QEwxCAqNRgWc=.7bd58812-1412-438d-bf24-a902356b6965@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <Sg0jgFP2e1AMMaY8hOHa6x4xl1pHMt0QEwxCAqNRgWc=.7bd58812-1412-438d-bf24-a902356b6965@github.com>
Message-ID: <Il_dfiQ_k7QduHb3daOL4lUCLihT1HXKkVK_1IcGstM=.45921b6d-fc9d-45d7-a72a-12a60989f6f8@github.com>

On Sat, 11 Oct 2025 03:24:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix trivial bug

I fixed for AArch64, and it works fine (in below) on Raspberry Pi 4.

----------------- 1687 -----------------
"ForkJoinPool-1-worker-2" #28 daemon prio=5 tid=0x0000ffff9c697a10 nid=1687 runnable [0x0000ffff70def000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x0000ffffa3b382e8      __syscall_cancel_arch + 0x28
0x0000ffffa3b68b7c      __clock_nanosleep + 0x3c
0x0000ffffa3b73740      __GI___nanosleep + 0x20
0x0000ffffa3b83f50      __sleep + 0x50
0x0000ffff8b15b278      <nep_invoker_blob>
0x0000ffff8b13bd54      * java.lang.invoke.LambdaForm$MH+0x0000000010087000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
0x0000ffff8b13bd54      * java.lang.invoke.LambdaForm$MH+0x0000000010090000.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Interpreted frame)
0x0000ffff8b13bd54      * jdk.internal.foreign.abi.DowncallStub+0x0000000010088000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x0000ffff8b13bd54      * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Interpreted frame)
0x0000ffff8b13bd54      * java.lang.invoke.LambdaForm$MH+0x000000001008e400.invoke(java.lang.Object, int) bci:44 (Interpreted frame)
0x0000ffff8b13bf24      * java.lang.invoke.LambdaForm$MH+0x000000001008cc00.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Interpreted frame)
0x0000ffff8b13bf24      * Test.run() bci:21 line:28 (Interpreted frame)
0x0000ffff8b13a3b8      <StubRoutines (continuation stubs)>
0x0000ffff8b13bf24      * jdk.internal.vm.Continuation.run() bci:122 line:248 (Interpreted frame)
0x0000ffff8b13bf24      * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Interpreted frame)
0x0000ffff8b13bf24      * java.lang.VirtualThread$$Lambda+0x00000000100fba70.run() bci:4 (Interpreted frame)
0x0000ffff8b13c5b4      * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:4 line:1753 (Interpreted frame)
0x0000ffff8b13bc50      * java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() bci:1 line:1745 (Interpreted frame)
0x0000ffff8b13bc50      * java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() bci:51 line:1662 (Interpreted frame)
0x0000ffff8b13bd54      * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Interpreted frame)
0x0000ffff8b13bf24      * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Interpreted frame)
0x0000ffff8b13bf24      * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Interpreted frame)
0x0000ffff8b13bf24      * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Interpreted frame)
0x0000ffff8b13749c      <StubRoutines (initial stubs)>
0x0000ffffa24d15c4      JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x474
0x0000ffffa24d1c48      JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x278
0x0000ffffa24d21e4      JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0x90
0x0000ffffa2668a14      thread_entry(JavaThread*, JavaThread*) + 0xc4
0x0000ffffa2510d18      JavaThread::thread_main_inner() + 0x104
0x0000ffffa30399fc      Thread::call_run() + 0xac
0x0000ffffa2b6c69c      thread_native_entry(Thread*) + 0x12c
0x0000ffffa3b2e8d4      start_thread + 0x404

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3393348999

From ysuenaga at openjdk.org  Sat Oct 11 14:58:10 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 11 Oct 2025 14:58:10 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux [v4]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <1zkXIKlR0K0ZFR32Z62RDHOUezVSgcSAHUt3EUjfY2w=.2f7db4ef-351f-44ae-a349-aaccdb56fa37@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/2f3eee62..915fca8d

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

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

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

From ysuenaga at openjdk.org  Sat Oct 11 14:58:11 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 11 Oct 2025 14:58:11 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux
In-Reply-To: <GRgx2q_VzV4EYyfw53ws1Csp7UowrcriX3uAnZabOVM=.5621e1e8-3ca0-4647-b223-9908ad1faf1d@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
 <GRgx2q_VzV4EYyfw53ws1Csp7UowrcriX3uAnZabOVM=.5621e1e8-3ca0-4647-b223-9908ad1faf1d@github.com>
Message-ID: <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com>

On Fri, 10 Oct 2025 20:38:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
>> 
>> "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
>>  - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
>>  - Test.run() @bci=21, line=28 (Interpreted frame)
>>  - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
>>  - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame)
>>  - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
>>  - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
>>  - java.util.concurrent.F...
>
>> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
>>
> These two different stack traces are expected and depend on whether the vthread was unmounted or not. With the current test this is timing dependent. You can run the test commenting out the `System.out.println` call, and then again replacing it with `Thread.yield()`. The string `<StubRoutines (continuation stubs)>` does look like from a previous version though. Even on x64 I see the `enterSpecial` frame printed out, and it matches what I would expect based on the patch.

@pchilano I reproduce the problem with `Thread.yield()`. Thanks! So I added test in the latest commit. I believe it works on both AMD64 and AArch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3393398658

From kbarrett at openjdk.org  Sun Oct 12 00:06:20 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 12 Oct 2025 00:06:20 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v3]
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <holL4u7YH_qUz7Fd8SjosCV8z0N3sYDRpU1jbvi5O1Y=.4add5b4a-d0e1-48e8-8de3-354c4b3e08f7@github.com>

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into stdlib-header-wrappers
 - jrose comments
 - move tuple to undecided category
 - add wrapper for <type_traits>
 - add wrapper for <cstddef>
 - add wrapper for <limits>
 - style guide permits some standard library facilities

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

Changes: https://git.openjdk.org/jdk/pull/27601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27601&range=02
  Stats: 670 lines in 68 files changed: 430 ins; 134 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

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

From fyang at openjdk.org  Mon Oct 13 02:12:05 2025
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 13 Oct 2025 02:12:05 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux
In-Reply-To: <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
 <GRgx2q_VzV4EYyfw53ws1Csp7UowrcriX3uAnZabOVM=.5621e1e8-3ca0-4647-b223-9908ad1faf1d@github.com>
 <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com>
Message-ID: <kSOqZ8v1dFJdgrrMrmvxKSUWHvMzWtTeOU_S52Sgk_s=.e6ce7957-779a-43b4-9a7b-5d6777470c4f@github.com>

On Sat, 11 Oct 2025 14:54:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>>> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
>>>
>> These two different stack traces are expected and depend on whether the vthread was unmounted or not. With the current test this is timing dependent. You can run the test commenting out the `System.out.println` call, and then again replacing it with `Thread.yield()`. The string `<StubRoutines (continuation stubs)>` does look like from a previous version though. Even on x64 I see the `enterSpecial` frame printed out, and it matches what I would expect based on the patch.
>
> @pchilano I reproduce the problem with `Thread.yield()`. Thanks! So I added test in the latest commit. I believe it works on both AMD64 and AArch64.

@YaSuenag : 
Hi, I tried on linux-riscv64 and I see the assertion failure is triggering on this platform as well.
Seems that your changes are applicable to riscv64 with minor tweak. Maybe you can add this? Thanks.


diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
index e02e056f028..44c8f4c679c 100644
--- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
+++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
@@ -262,7 +262,13 @@ public Frame sender(RegisterMap regMap, CodeBlob cb) {
     }

     if (cb != null) {
-      return cb.isUpcallStub() ? senderForUpcallStub(map, (UpcallStub)cb) : senderForCompiledFrame(map, cb);
+      if (cb.isUpcallStub()) {
+        return senderForUpcallStub(map, (UpcallStub)cb);
+      } else if (cb.isContinuationStub()) {
+        return senderForContinuationStub(map, cb);
+      } else {
+        return senderForCompiledFrame(map, cb);
+      }
     }

     // Must be native-compiled frame, i.e. the marshaling code for native
@@ -348,6 +354,16 @@ private void updateMapWithSavedLink(RegisterMap map, Address savedFPAddr) {
     map.setLocation(fp, savedFPAddr);
   }

+  private Frame senderForContinuationStub(RISCV64RegisterMap map, CodeBlob cb) {
+    var contEntry = map.getThread().getContEntry();
+
+    Address senderSP = contEntry.getEntrySP();
+    Address senderPC = contEntry.getEntryPC();
+    Address senderFP = contEntry.getEntryFP();
+
+    return new RISCV64Frame(senderSP, senderFP, senderPC);
+  }
+
   private Frame senderForCompiledFrame(RISCV64RegisterMap map, CodeBlob cb) {
     if (DEBUG) {
       System.out.println("senderForCompiledFrame");
diff --git a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java
index 2565fdf9056..9b4fa067dc0 100644
--- a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java
+++ b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java
@@ -37,7 +37,7 @@
  * @test
  * @bug 8369505
  * @requires (os.family == "linux") & (vm.hasSA)
- * @requires (os.arch == "amd64" | os.arch == "aarch64")
+ * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64")
  * @library /test/lib
  * @run driver TestJhsdbJstackMixedWithVirtualThread
  */

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3395643581

From ysuenaga at openjdk.org  Mon Oct 13 03:08:57 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 13 Oct 2025 03:08:57 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux [v5]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <Et1I48DWARG-Nc4PRYD-Wdu2_BuUKlgSBoAEZTbWdAM=.915303a3-0fd5-4a30-9a42-35e1432a6c2e@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Apply changes to RISC-V code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/915fca8d..57294d7c

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

  Stats: 18 lines in 2 files changed: 16 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728

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

From ysuenaga at openjdk.org  Mon Oct 13 03:08:58 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 13 Oct 2025 03:08:58 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux
In-Reply-To: <kSOqZ8v1dFJdgrrMrmvxKSUWHvMzWtTeOU_S52Sgk_s=.e6ce7957-779a-43b4-9a7b-5d6777470c4f@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
 <GRgx2q_VzV4EYyfw53ws1Csp7UowrcriX3uAnZabOVM=.5621e1e8-3ca0-4647-b223-9908ad1faf1d@github.com>
 <7x2Q8XpYmzX-CXSKhmlashbJFWr8Ojxf9g4MI7zHKdw=.73118555-6c53-49d9-a99e-392fd115fbd7@github.com>
 <kSOqZ8v1dFJdgrrMrmvxKSUWHvMzWtTeOU_S52Sgk_s=.e6ce7957-779a-43b4-9a7b-5d6777470c4f@github.com>
Message-ID: <K9UL-VYMjge8MeuXoAPg4EZm34ZYPf0GQdoMFi5w4Pk=.493a0f49-6d70-4c56-b613-28f4ca29cde3@github.com>

On Mon, 13 Oct 2025 02:09:50 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> @pchilano I reproduce the problem with `Thread.yield()`. Thanks! So I added test in the latest commit. I believe it works on both AMD64 and AArch64.
>
> @YaSuenag : 
> Hi, I tried on linux-riscv64 and I see the assertion failure is triggering on this platform as well.
> Seems that your changes are applicable to riscv64 with minor tweak. Maybe you can add this? Thanks.
> 
> 
> diff --git a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
> index e02e056f028..44c8f4c679c 100644
> --- a/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
> +++ b/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/riscv64/RISCV64Frame.java
> @@ -262,7 +262,13 @@ public Frame sender(RegisterMap regMap, CodeBlob cb) {
>      }
> 
>      if (cb != null) {
> -      return cb.isUpcallStub() ? senderForUpcallStub(map, (UpcallStub)cb) : senderForCompiledFrame(map, cb);
> +      if (cb.isUpcallStub()) {
> +        return senderForUpcallStub(map, (UpcallStub)cb);
> +      } else if (cb.isContinuationStub()) {
> +        return senderForContinuationStub(map, cb);
> +      } else {
> +        return senderForCompiledFrame(map, cb);
> +      }
>      }
> 
>      // Must be native-compiled frame, i.e. the marshaling code for native
> @@ -348,6 +354,16 @@ private void updateMapWithSavedLink(RegisterMap map, Address savedFPAddr) {
>      map.setLocation(fp, savedFPAddr);
>    }
> 
> +  private Frame senderForContinuationStub(RISCV64RegisterMap map, CodeBlob cb) {
> +    var contEntry = map.getThread().getContEntry();
> +
> +    Address senderSP = contEntry.getEntrySP();
> +    Address senderPC = contEntry.getEntryPC();
> +    Address senderFP = contEntry.getEntryFP();
> +
> +    return new RISCV64Frame(senderSP, senderFP, senderPC);
> +  }
> +
>    private Frame senderForCompiledFrame(RISCV64RegisterMap map, CodeBlob cb) {
>      if (DEBUG) {
>        System.out.println("senderForCompiledFrame");
> diff --git a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java
> index 2565fdf9056..9b4fa067dc0 100644
> --- a/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java
> +++ b/test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java
> @@ -37,7 +37,7 @@
>   * @test
>   * @bug 8369505
>   * @requires (os.family == "linux") & (vm.hasSA)
> - * @requires (os.arch == "amd64" | os.arch == "aarch64")
> + * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64")
>   * @library /test/lib
>   * @run driver TestJhsdbJstac...

@RealFYang Thanks a lot! I applied your change to this PR!

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3395709070

From cjplummer at openjdk.org  Mon Oct 13 05:08:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 Oct 2025 05:08:08 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 on Linux [v5]
In-Reply-To: <Et1I48DWARG-Nc4PRYD-Wdu2_BuUKlgSBoAEZTbWdAM=.915303a3-0fd5-4a30-9a42-35e1432a6c2e@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <Et1I48DWARG-Nc4PRYD-Wdu2_BuUKlgSBoAEZTbWdAM=.915303a3-0fd5-4a30-9a42-35e1432a6c2e@github.com>
Message-ID: <GxyZW2e6R0ugoPRfp0dEYikPNlyFEGXeI8PI-VpsBAQ=.dbce234a-58a8-4430-b954-14414e8c8bed@github.com>

On Mon, 13 Oct 2025 03:08:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply changes to RISC-V code

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 39:

> 37:  * @test
> 38:  * @bug 8369505
> 39:  * @requires (os.family == "linux") & (vm.hasSA)

I think it would be good to run this on macosx also, but it can't be run --mixed. I did reproduce the exception on macosx without --mixed. It doesn't however produce the "<StubRoutines (continuation stubs)>" frame. The test would need to be modified to instead check for the exception.

Probably we should run this on Windows also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2425225335

From stefank at openjdk.org  Mon Oct 13 06:15:07 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 13 Oct 2025 06:15:07 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v3]
In-Reply-To: <holL4u7YH_qUz7Fd8SjosCV8z0N3sYDRpU1jbvi5O1Y=.4add5b4a-d0e1-48e8-8de3-354c4b3e08f7@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <holL4u7YH_qUz7Fd8SjosCV8z0N3sYDRpU1jbvi5O1Y=.4add5b4a-d0e1-48e8-8de3-354c4b3e08f7@github.com>
Message-ID: <gDALmhCV8DGJe0F2WpD121C-uE39agVerfrrbJQApzk=.9e2ac3d3-b898-4cd1-8c8d-5c47b8365577@github.com>

On Sun, 12 Oct 2025 00:06:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3330092146

From kevinw at openjdk.org  Mon Oct 13 08:16:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 13 Oct 2025 08:16:28 GMT
Subject: RFR: 8369574: Remove
 javax/management/remote/mandatory/connection/BrokenConnectionTest.java from
 ProblemList-Virtual.txt
In-Reply-To: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
References: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
Message-ID: <poKon75o18VrQBi5onJBkfiZj-HzFZ5ok2kLnQgmxGE=.ee5ff166-9636-4145-9d70-021bb125d201@github.com>

On Fri, 10 Oct 2025 15:51:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted (JDK-8307369) like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now.  Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

Thanks Albert!

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

PR Comment: https://git.openjdk.org/jdk/pull/27747#issuecomment-3396350764

From kevinw at openjdk.org  Mon Oct 13 08:16:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 13 Oct 2025 08:16:28 GMT
Subject: Integrated: 8369574: Remove
 javax/management/remote/mandatory/connection/BrokenConnectionTest.java from
 ProblemList-Virtual.txt
In-Reply-To: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
References: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
Message-ID: <Vo5fLaxqH-UKTPpHWMiWu5yyXlm7n44sWcmmwuvChCg=.d5b7467f-77f3-4e86-a0a5-6db895acf9a2@github.com>

On Fri, 10 Oct 2025 15:51:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted (JDK-8307369) like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now.  Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

This pull request has now been integrated.

Changeset: 1605e839
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1605e8392e8efa972134a0bf3eecad0ed4f992fa
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8369574: Remove javax/management/remote/mandatory/connection/BrokenConnectionTest.java from ProblemList-Virtual.txt

Reviewed-by: ayang

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

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

From aboldtch at openjdk.org  Mon Oct 13 08:32:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 08:32:03 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
Message-ID: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>

> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
> 
> Example stack trace:
> 
> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
> 
> 
> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Check !cont.entry()->is_virtual_thread()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27716/files
  - new: https://git.openjdk.org/jdk/pull/27716/files/4ec7ce98..d5a2cc0c

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

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

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

From aboldtch at openjdk.org  Mon Oct 13 08:34:05 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 13 Oct 2025 08:34:05 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v2]
In-Reply-To: <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>
Message-ID: <cMWi0vMnsQ6QBt4SL2ndlCIfhw9n_XlDOMxahm4opDc=.ba235c7d-7d28-44b1-aa4b-3c7f0e765105@github.com>

On Fri, 10 Oct 2025 06:29:40 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - sspitsyn patch
>  - Revert "8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state"
>    
>    This reverts commit e133d9b73125ea907111a2a869ed824aca9bfa3d.

Pushed the latest patch. 

The intent of this bug fix was to solve the safepoint (check) issue. 

Is there anything else we should fix as part of this bug fix? Especially given that there is interest in back-porting JDK-8368159.

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3396411952

From ysuenaga at openjdk.org  Mon Oct 13 08:34:57 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 13 Oct 2025 08:34:57 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 [v6]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <zEnivAoRBuxgDJO6dfCB4QFg1g2hH2NLwh0qv75xzFQ=.d75d0f29-71ab-425f-a82b-eb9b25ccd5e7@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/57294d7c..25d883f7

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

  Stats: 18 lines in 2 files changed: 9 ins; 3 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27728/head:pull/27728

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

From ysuenaga at openjdk.org  Mon Oct 13 08:35:01 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 13 Oct 2025 08:35:01 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 [v5]
In-Reply-To: <GxyZW2e6R0ugoPRfp0dEYikPNlyFEGXeI8PI-VpsBAQ=.dbce234a-58a8-4430-b954-14414e8c8bed@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <Et1I48DWARG-Nc4PRYD-Wdu2_BuUKlgSBoAEZTbWdAM=.915303a3-0fd5-4a30-9a42-35e1432a6c2e@github.com>
 <GxyZW2e6R0ugoPRfp0dEYikPNlyFEGXeI8PI-VpsBAQ=.dbce234a-58a8-4430-b954-14414e8c8bed@github.com>
Message-ID: <h31e_5FEhkXPjo5hsmqVuw76uqswIj-fbDyv67FI6Ac=.f65e1299-3461-4631-b825-96a327883410@github.com>

On Mon, 13 Oct 2025 05:05:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply changes to RISC-V code
>
> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 39:
> 
>> 37:  * @test
>> 38:  * @bug 8369505
>> 39:  * @requires (os.family == "linux") & (vm.hasSA)
> 
> I think it would be good to run this on macosx also, but it can't be run --mixed. I did reproduce the exception on macosx without --mixed. It doesn't however produce the "<StubRoutines (continuation stubs)>" frame. The test would need to be modified to instead check for the exception.
> 
> Probably we should run this on Windows also.

I updated testcase to run this on other platforms - runs `jhsdb jstack` without `--mixed` and checks stderr.

I tested on Windows, but I didn't see any errors - I guess `jhsdb jstack` couldn't unwind stacks on Windows, thus it did not reach continuation stub. But it is different problem.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2425558934

From jsjolen at openjdk.org  Mon Oct 13 08:44:07 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 13 Oct 2025 08:44:07 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v3]
In-Reply-To: <WZnPF70M36SG11iLNeHGMPDJZFCWGMCX7FyKKL4tjCg=.ea44cdd2-269f-428e-a325-051e15ab71a5@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <8yuoztJS9xFrnxl2LHCptA8HtSU8dpXiifFrRTaHIOE=.010c05ff-3bbf-41f5-8a85-63f2dc1e0fa3@github.com>
 <Y5fpZaXEol86BDAWaNeumIOlF4MDpLj-V9Lntefs-uw=.ff26ff78-e136-49cc-895a-79122ff30a34@github.com>
 <WZnPF70M36SG11iLNeHGMPDJZFCWGMCX7FyKKL4tjCg=.ea44cdd2-269f-428e-a325-051e15ab71a5@github.com>
Message-ID: <ldP6l9HXdO3wyvdyjBPCamdbiNFE4iErR11AATcN7s4=.b118610e-b617-401a-8252-ad45f371b45d@github.com>

On Wed, 8 Oct 2025 18:48:12 GMT, John R Rose <jrose at openjdk.org> wrote:

>> I have a different take on the distinction between forbidden and undecided. I
>> think of forbidden features as being those where there are good arguments
>> against. Whereas I think of undecided as perhaps having wishy washy arguments
>> in either direction, or even not seriously thought about. But good arguments
>> against can be overcome by better arguments in favor.
>> 
>> But I can see how someone else might take that distinction differently.
>> 
>> I also admit to being somewhat biased against tuple in particular. I've seen
>> a few pretty terrible uses... one was even my fault!
>> 
>> So okay, I'll recategorize tuple.
>
> I'm OK with cracking the door open on tuple, but I have to say I do like API-specific names very much.  (And `fst`/`snd` or whatever are not API specific; they are tuple-specific!)  So the guidance that steers folks towards name-based techniques, instead of positional techniques, is still sound.
> 
> I even like out-args, personally, in cases where the out-arg is for a return value that is clearly secondary to the main return value.  Example:  Main value is boolean, and out-arg is some hint about why the main value is what it is, like a position.  The out-arg can also be optional if a null pointer is tolerated (explicitly documented as such, of course), which is useful when the out-arg costs extra to compute.  (A separate boolean arg is OK for such uses also, but null pointers are so darn useful as optionality sentinels!)  Note that our TRAPS/THREAD macro system can be viewed as a giant set of out-args.

Often, we can use more "specialized" tuples like `Maybe<T, Error>`, in which case it's fine to have the 'generic' `_value`, `_error` slots. Having a bigger sign saying "hey, hey!! this might fail!!!!" is good, it makes bugs related to missing error handling more shallow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2425580500

From alanb at openjdk.org  Mon Oct 13 09:51:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 09:51:10 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>
Message-ID: <61w8E0BpN40jLzkmF8Yslw2ouRneaninNCWhr3b9SW8=.6562492c-345e-4bf5-a2f9-c9a4dec39097@github.com>

On Thu, 9 Oct 2025 13:59:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Questions that this change brings up to me:
> 
> Is there a general understanding or a statement of what it means to be standard or JDK-specific in this area? If previous JSRs which specified JMX independently were the spec, and are these days part of the JDK Platform, what does it mean to be standard or JDK-specific?

It's similar to standard APIs vs. JDK-specific APIs. A management interface with HotSpot VM or JDK-specific attributes or operations would be a candidate for the jdk.management module rather than the java.management module. 

I wasn't directly involved in JSR-174 but there were three VM vendors in the EG at the time. The management interfaces that were defined had to be feasible to implement on all. There was interest in further management interfaces and the Sun JDK defined its extensions in com.sun.management. The word "extension" is significant here because asking the platform MBeanServer for a standard MXBean (either directly or via the standard object name) provides access to additional attributes/operations defined by the extension. It might seem a bit strange to see csm.ThreadMXBean extends jlm.ThreadMXBean, but that was the pattern established back in JDK 5. A lookup of say "java.lang:type=Threading" gives access to csm.ThreadMXBean with the additional attributes and operations defined in the subclass. It may be that some of the attributes or operations in these extensions could be proposed for the standard management interfaces, not clear if this is worth doing. TBH, I think the bigger issue is th
 at these management interfaces haven't evolved significantly, they pre-date fully concurrent GCs and other significant improvements.

Note that are some management interfaces that are clearly HotSpot VM or JDK-specific, e.g. csm.HotSpotDiagnosticMXBean and jdk.management.VirtualThreadSchedulerMXBean.

As regards the proposal here. I think the API docs will need work. The standard APIs don't know about non-Java threads. This is why it can't speak of "driver threads" and the "VM thread". It seems reasonable to introduce the notion that garbage collection consuming CPU cycle but anything about STW vs. concurrent GCs is more for an implNote. One of the goals, as I understand it, is to use it in conjunction with JDK-specific OperatingSystemMXBean "processCpuTime" attribute. It's possible to cross link in API docs but its relation to that attribute can't be normative if in a standard API. So I think focus on the specifying the attribute first. So far I think Jonas has demonstrated that it is feasible to implementation as either a standard or extension.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3396681608

From sspitsyn at openjdk.org  Mon Oct 13 09:58:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 13 Oct 2025 09:58:05 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
Message-ID: <VLzXf7S8Vl7tsz8B9p5udo8b6AdaveGAgMXP9G0mLt8=.e4463a25-9992-4367-a7c7-5557dd7391cc@github.com>

On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check !cont.entry()->is_virtual_thread()

Looks good. Thank you for taking care about this!

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27716#pullrequestreview-3330756505

From duke at openjdk.org  Mon Oct 13 11:45:02 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 13 Oct 2025 11:45:02 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
Message-ID: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>

> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
> 
> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.

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

 - Merge from the main branch
 - Address review comments
 - Address review comments
 - Address review comments
 - The patch is contributed by @TheRealMDoerr
 - Offset the deoptimization handler entry point
   
   Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
 - Revert "Ensure stub code is not adjacent to a call"
 - Ensure stub code is not adjacent to a call
 - Address review comments
 - 8365047: Remove exception handler stub code in C2
   
   The C2 exception handler stub code is only a trampoline to the
   generated exception handler blob. This change removes the extra
   step on the way to the generated blob.
   
   According to some comments in the source code, the exception handler
   stub code used to be patched upon deoptimization, however presumably
   these comments are outdated as the patching upon deoptimization happens
   for post-call NOPs only.

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

Changes: https://git.openjdk.org/jdk/pull/26678/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26678&range=06
  Stats: 376 lines in 37 files changed: 98 ins; 212 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/26678.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26678/head:pull/26678

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

From duke at openjdk.org  Mon Oct 13 11:49:21 2025
From: duke at openjdk.org (Ruben)
Date: Mon, 13 Oct 2025 11:49:21 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v5]
In-Reply-To: <pQEeXRn0BGkvHDMZx4rznPIGvqj1KdrDZTsii9H64B0=.6fda502d-d48b-4355-9986-61ed384d46b9@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <RRBHEANMwk5TyEPkAaxJrPEHwBNJREoWUwB1vEY7Kec=.583fbe61-46a0-4143-8244-4d15384a53bc@github.com>
 <mk_eykgSPSzczsDhuvDWMf4FT52Y56N1hxt4bpJmMJY=.32ae7162-8abc-4bb6-b398-308d0b8a1cff@github.com>
 <ZH2HI7Mjj-eS3lG0XqcvP5HhoAufj_I63_XVskDMPqw=.6f49fad1-ba76-445a-8b4d-8146574b107b@github.com>
 <pQEeXRn0BGkvHDMZx4rznPIGvqj1KdrDZTsii9H64B0=.6fda502d-d48b-4355-9986-61ed384d46b9@github.com>
Message-ID: <Vrxfn4OCziv6KmGpnI7U5QfkCNubKMCeNjwbIqCP6WU=.d1a803e9-3783-420d-96a5-0aa83c65d287@github.com>

On Mon, 29 Sep 2025 10:36:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Thanks for the feedback. I followed the current guideline at https://openjdk.org/guide/#copyright-headers which advises:
>> 
>>> If your affiliation doesn?t have a copyright notice, again consult your legal representative to see if you should add one.
>> 
>> If the guideline isn't applicable or if there is a more detailed guidance on when Copyright header should or should not be added, I'd appreciate further advice.
>
> Here are some arguments why I wouldn't do it:
> - We usually don't add Copyright headers to existing files. Only to new ones we created. Many contributors are doing the same AFAIK. (Maybe only for very significant contributions to a file.)
> - The Linux Foundation has listed reasons "Why not list every copyright holder?" https://www.linuxfoundation.org/blog/blog/copyright-notices-in-open-source-software-projects
> - OpenJDK headers say "DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER."

@TheRealMDoerr, @bulasevich,
Thank you for your detailed response.
I've removed these lines following your request.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26678#discussion_r2426097487

From mdoerr at openjdk.org  Mon Oct 13 13:30:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 13 Oct 2025 13:30:38 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <PBTFe44R7V1fN0pxmrmIih7XtjV0JcJW32TI49QN-Eo=.08c35039-b293-4719-9606-331aefa8f939@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

Thank you!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26678#pullrequestreview-3331641868

From pchilanomate at openjdk.org  Mon Oct 13 13:50:01 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Oct 2025 13:50:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state
In-Reply-To: <VBJ6p35zrvNFjI5-stHYmJz5ux3-136ZlPnhIX6EJ2Y=.1def8864-c2e2-4dfc-93b3-2c06dd08b828@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <ph9IfD5dOXZ8NSj1aeqFjsRvZIwJ7dp7BFbiiQqU8mo=.78154be2-3380-4552-929c-f577e0dc79fd@github.com>
 <FvbPVdZuKb5_D9yuxkOLrgwbcjxSypwupcaeCkHpH0g=.03ef9e72-ff51-4f11-b010-755ef9f491eb@github.com>
 <spCd4-cLsmd1JESWxee0dCf1iN0u8XTTzBqG4nCMX20=.cfffde43-5653-4a66-a327-486908820f86@github.com>
 <FdJkZgALIZzMRdLglerupCAJKLsZTYdCc5MMvW3G3Dg=.edff5c1a-6106-46bd-9582-f1adc9f7cc70@github.com>
 <75M_gZ6GY62WQHT1HTMwtJdxgKzJX972e7conVaKdC4=.6a02ba49-3d60-41e4-adbc-096d5299f95f@github.com>
 <VBJ6p35zrvNFjI5-stHYmJz5ux3-136ZlPnhIX6EJ2Y=.1def8864-c2e2-4dfc-93b3-2c06dd08b828@github.com>
Message-ID: <Q8DVT07X855UWfbT3Rp8IcJknheT_vTMZdU-aLgkBM0=.9b28a26c-3644-4c13-a925-106961583146@github.com>

On Fri, 10 Oct 2025 22:29:56 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> > Yes, but we are calling the other overload of freeze_epilog() which only logs and verifies the continuation. : )
> 
> I see, thanks! Do I understand it right that there is no need to call the `jvmti_yield_cleanup()` in this case? Does the preempt_epilog() is called for pure continuations as well?
> 
> I've filed new JVMTI bug: [8369609](https://bugs.openjdk.org/browse/JDK-8369609) Continuations preempt_epilog is missing a call to invalidate_jvmti_stack
>
Yes, only `invalidate_jvmti_stack` is missing since `preempt_epilog` is only called in the virtual thread case.
Thanks for filing the bug Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3397611850

From pchilanomate at openjdk.org  Mon Oct 13 13:53:10 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 13 Oct 2025 13:53:10 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
Message-ID: <Q6PRyNqR8VkkgagomZdBcBmj-qAFmUjYkmj_Auo4cCw=.1b9ea230-0f8b-4531-9edb-f61c01c38d6f@github.com>

On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check !cont.entry()->is_virtual_thread()

Looks good to me, thanks.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27716#pullrequestreview-3331727767

From cjplummer at openjdk.org  Mon Oct 13 20:05:12 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 Oct 2025 20:05:12 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 [v6]
In-Reply-To: <zEnivAoRBuxgDJO6dfCB4QFg1g2hH2NLwh0qv75xzFQ=.d75d0f29-71ab-425f-a82b-eb9b25ccd5e7@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <zEnivAoRBuxgDJO6dfCB4QFg1g2hH2NLwh0qv75xzFQ=.d75d0f29-71ab-425f-a82b-eb9b25ccd5e7@github.com>
Message-ID: <fKZAxeB24pXY-Rc06VrRxRpcU2hhbypzlPavzuQoHTM=.28311787-5d3d-4405-8877-53b91f2bbbaa@github.com>

On Mon, 13 Oct 2025 08:34:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcase

Changes requested by cjplummer (Reviewer).

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 40:

> 38:  * @bug 8369505
> 39:  * @requires vm.hasSA
> 40:  * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64")

You need to include `os.arch == "x86_64"` in order to run on macosx-x64.

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 42:

> 40:  * @requires (os.arch == "amd64" | os.arch == "aarch64" | os.arch == "riscv64")
> 41:  * @library /test/lib
> 42:  * @run driver TestJhsdbJstackMixedWithVirtualThread

This test needs to be renamed since it no longer passes `--mixed`.

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 62:

> 60:         System.err.println(out.getStderr());
> 61: 
> 62:         out.stderrShouldBeEmptyIgnoreDeprecatedWarnings();

This check doesn't seem to be working. I disabled your fix and see the `must have non-zero frame size` exception in the log, but the test still passed. I think the exception is going to System.out.

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

PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3332719455
PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427105111
PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427210111
PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427109788

From cjplummer at openjdk.org  Mon Oct 13 20:05:14 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 13 Oct 2025 20:05:14 GMT
Subject: RFR: 8369505: jhsdb jstack --mixed cannot handle continuation stub
 [v5]
In-Reply-To: <h31e_5FEhkXPjo5hsmqVuw76uqswIj-fbDyv67FI6Ac=.f65e1299-3461-4631-b825-96a327883410@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <Et1I48DWARG-Nc4PRYD-Wdu2_BuUKlgSBoAEZTbWdAM=.915303a3-0fd5-4a30-9a42-35e1432a6c2e@github.com>
 <GxyZW2e6R0ugoPRfp0dEYikPNlyFEGXeI8PI-VpsBAQ=.dbce234a-58a8-4430-b954-14414e8c8bed@github.com>
 <h31e_5FEhkXPjo5hsmqVuw76uqswIj-fbDyv67FI6Ac=.f65e1299-3461-4631-b825-96a327883410@github.com>
Message-ID: <jdDmwmFUgPLIk4qt-qTZF69sM1MFfwD1jl-0brvXIjs=.34d8272b-2137-4349-924d-04b1da203a2a@github.com>

On Mon, 13 Oct 2025 08:31:05 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithVirtualThread.java line 39:
>> 
>>> 37:  * @test
>>> 38:  * @bug 8369505
>>> 39:  * @requires (os.family == "linux") & (vm.hasSA)
>> 
>> I think it would be good to run this on macosx also, but it can't be run --mixed. I did reproduce the exception on macosx without --mixed. It doesn't however produce the "<StubRoutines (continuation stubs)>" frame. The test would need to be modified to instead check for the exception.
>> 
>> Probably we should run this on Windows also.
>
> I updated testcase to run this on other platforms - runs `jhsdb jstack` without `--mixed` and checks stderr.
> 
> I tested on Windows, but I didn't see any errors - I guess `jhsdb jstack` couldn't unwind stacks on Windows, thus it did not reach continuation stub. But it is different problem.

On Windows I am seeing the exception (with your fix disabled):


"ForkJoinPool-1-worker-1" #30 daemon prio=5 tid=0x000001567d6bcdc0 nid=2588 runnable [0x00000002d35fe000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
 - java.lang.invoke.LambdaForm$MH+0x0000000026047800.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000000002604e400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
 - jdk.internal.foreign.abi.DowncallStub+0x0000000026048800.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.LambdaForm$DMH+0x0000000026048c00.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000000002604d800.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
 - java.lang.invoke.LambdaForm$MH+0x000000002604d400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
 - LingeredAppWithVirtualThread.run() @bci=15, line=65 (Interpreted frame)

Error occurred during stack walking:
sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size

With your fix enabled, I see the full expected stack, so it seems to be working.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427225103

From sspitsyn at openjdk.org  Mon Oct 13 22:04:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 13 Oct 2025 22:04:01 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v2]
In-Reply-To: <cMWi0vMnsQ6QBt4SL2ndlCIfhw9n_XlDOMxahm4opDc=.ba235c7d-7d28-44b1-aa4b-3c7f0e765105@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <QNorR5omVjf6S9FDmqhjnYLHMCRQVaIeLAHDNh3X73A=.1d91f28c-0342-4928-b7e8-92c6018b6704@github.com>
 <cMWi0vMnsQ6QBt4SL2ndlCIfhw9n_XlDOMxahm4opDc=.ba235c7d-7d28-44b1-aa4b-3c7f0e765105@github.com>
Message-ID: <dHrdYEpLqJpuLcAMIc1zupWflB9OdY6eu9fXRVWKfhk=.789360c6-cd98-4557-a0b9-27012dad5db7@github.com>

On Mon, 13 Oct 2025 08:31:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> The intent of this bug fix was to solve the safepoint (check) issue.

Agreed. But thank you for fixing the additional issue pointed out by Patricio!

> Is there anything else we should fix as part of this bug fix?

The fix is good as is, thanks!

> Especially given that there is interest in back-porting JDK-8368159.

I'm curios who do you know is interested in back-porting JDK-8368159. I considered to back-port it but now it needs to be back-ported together with this one: JDK-8369482.

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3399182611

From ysuenaga at openjdk.org  Tue Oct 14 01:04:47 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 14 Oct 2025 01:04:47 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v7]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <NoSo51v8KTKJYSTNCZZLjHs6Ra8fzLw2hYinnk-3JNg=.f03afee3-5683-4f49-aeba-04b3852d1b47@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/25d883f7..04d93099

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

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

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

From ysuenaga at openjdk.org  Tue Oct 14 01:04:47 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 14 Oct 2025 01:04:47 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub
In-Reply-To: <invP6sQ5jfAy9_oncbxq9ZZNVzHLNJRe8hcyMwCy1E8=.637df4ab-3eed-41f6-af61-595b1af93be8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
 <invP6sQ5jfAy9_oncbxq9ZZNVzHLNJRe8hcyMwCy1E8=.637df4ab-3eed-41f6-af61-595b1af93be8@github.com>
Message-ID: <HiBh9EY3mf9KPhxmJUVIs1JX0s2YWwPflL2yA3160F4=.f910dc7a-8d39-4fdc-9b11-423543c9ba11@github.com>

On Sat, 11 Oct 2025 05:09:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I applied the changes to AARCH64Frame.java and they seem to fix the issue with the exception. I'm seeing two different stack traces (see below), and neither is identical to your fixed stack trace. I don't see `<StubRoutines (continuation stubs)>`. Instead I see a frame for `jdk.internal.vm.Continuation.enterSpecial()`. Also, I don't see `<StubRoutines (initial stubs)>` or any of the frames that come after it. Maybe these are just expected platform differences.
>> 
>> "ForkJoinPool-1-worker-5" #34 daemon prio=5 tid=0x0000000159051c10 nid=34819 runnable [0x0000000172761000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe01047000.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe01054800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
>>  - jdk.internal.foreign.abi.DowncallStub+0x000003fe01048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$DMH+0x000003fe01048400.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104f400.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
>>  - java.lang.invoke.LambdaForm$MH+0x000003fe0104e400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
>>  - Test.run() @bci=21, line=28 (Interpreted frame)
>>  - jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) @bci=0 (Compiled frame)
>>  - jdk.internal.vm.Continuation.run() @bci=152, line=251 (Interpreted frame)
>>  - java.lang.VirtualThread.runContinuation() @bci=100, line=293 (Interpreted frame)
>>  - java.lang.VirtualThread$$Lambda+0x000003fe01027670.run() @bci=4 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=4, line=1753 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$RunnableExecuteAction.compute() @bci=1, line=1745 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask$InterruptibleTask.exec() @bci=51, line=1662 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinTask.doExec() @bci=10, line=511 (Interpreted frame)
>>  - java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) @bci=5, line=1450 (Interpreted frame)
>>  - java.util.concurrent.F...
>
>> @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least).
> 
> I did not, and unfortunately --mixed is not support on OSX.

@plummercj Thanks for your comment! I revised testcase in the latest commit. Could you review again?

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3399578469

From ysuenaga at openjdk.org  Tue Oct 14 01:04:47 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 14 Oct 2025 01:04:47 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v5]
In-Reply-To: <jdDmwmFUgPLIk4qt-qTZF69sM1MFfwD1jl-0brvXIjs=.34d8272b-2137-4349-924d-04b1da203a2a@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <Et1I48DWARG-Nc4PRYD-Wdu2_BuUKlgSBoAEZTbWdAM=.915303a3-0fd5-4a30-9a42-35e1432a6c2e@github.com>
 <GxyZW2e6R0ugoPRfp0dEYikPNlyFEGXeI8PI-VpsBAQ=.dbce234a-58a8-4430-b954-14414e8c8bed@github.com>
 <h31e_5FEhkXPjo5hsmqVuw76uqswIj-fbDyv67FI6Ac=.f65e1299-3461-4631-b825-96a327883410@github.com>
 <jdDmwmFUgPLIk4qt-qTZF69sM1MFfwD1jl-0brvXIjs=.34d8272b-2137-4349-924d-04b1da203a2a@github.com>
Message-ID: <erBgpEPRt9ibL8Uwx8BTejrwG_ZLnBm5QJgP74SluSY=.e0988b6e-9cf7-4a5b-ab03-e610c0d6d589@github.com>

On Mon, 13 Oct 2025 19:57:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> I updated testcase to run this on other platforms - runs `jhsdb jstack` without `--mixed` and checks stderr.
>> 
>> I tested on Windows, but I didn't see any errors - I guess `jhsdb jstack` couldn't unwind stacks on Windows, thus it did not reach continuation stub. But it is different problem.
>
> On Windows I am seeing the exception (with your fix disabled):
> 
> 
> "ForkJoinPool-1-worker-1" #30 daemon prio=5 tid=0x000001567d6bcdc0 nid=2588 runnable [0x00000002d35fe000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
>  - java.lang.invoke.LambdaForm$MH+0x0000000026047800.invoke(java.lang.Object, long, int) @bci=10 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000000002604e400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) @bci=21 (Interpreted frame)
>  - jdk.internal.foreign.abi.DowncallStub+0x0000000026048800.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) @bci=44 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$DMH+0x0000000026048c00.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) @bci=14 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000000002604d800.invoke(java.lang.Object, int) @bci=44 (Interpreted frame)
>  - java.lang.invoke.LambdaForm$MH+0x000000002604d400.invoke_MT(java.lang.Object, int, java.lang.Object) @bci=18 (Interpreted frame)
>  - LingeredAppWithVirtualThread.run() @bci=15, line=65 (Interpreted frame)
> 
> Error occurred during stack walking:
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
> 
> With your fix enabled, I see the full expected stack, so it seems to be working.

I tested only mixed mode, sorry. I could reproduce the problem on Windows, and I confirmed the problem has gone with this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427647746

From ysuenaga at openjdk.org  Tue Oct 14 01:04:47 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 14 Oct 2025 01:04:47 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v6]
In-Reply-To: <fKZAxeB24pXY-Rc06VrRxRpcU2hhbypzlPavzuQoHTM=.28311787-5d3d-4405-8877-53b91f2bbbaa@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <zEnivAoRBuxgDJO6dfCB4QFg1g2hH2NLwh0qv75xzFQ=.d75d0f29-71ab-425f-a82b-eb9b25ccd5e7@github.com>
 <fKZAxeB24pXY-Rc06VrRxRpcU2hhbypzlPavzuQoHTM=.28311787-5d3d-4405-8877-53b91f2bbbaa@github.com>
Message-ID: <UOYwayCCt4iQigzxtTS7ntm9Np_fDWdBNbx-9Ej1R-M=.67aea7e5-8d1a-461e-b0e2-502cfa4ce8e9@github.com>

On Mon, 13 Oct 2025 19:07:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase
>
> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java line 62:
> 
>> (failed to retrieve contents of file, check the PR for context)
> This check doesn't seem to be working. I disabled your fix and see the `must have non-zero frame size` exception in the log, but the test still passed. I think the exception is going to System.out.

I added test whether the message appears in output, and it works.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2427649014

From ysuenaga at openjdk.org  Tue Oct 14 02:03:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 14 Oct 2025 02:03:48 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v8]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <ydPZQc3CS3aCTo9nqiekIHYJ8mHnrkMWJYu9Gk2Uxu4=.084e1ed1-fe52-4ea0-8944-a0e34e1576b9@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Switch argument of s(S)leep between Windows API and POSIX function

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/04d93099..e8090faf

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

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

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

From ysuenaga at openjdk.org  Tue Oct 14 05:27:46 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 14 Oct 2025 05:27:46 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v9]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <GnJa0HsJtd4nsyhs3ltDLl2wwuoOUgvsLRjOSyrdQwU=.f627322c-dc7b-4422-8192-e0981fbdf94b@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update TestJhsdbJstackWithVirtualThread.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/e8090faf..b82bb9aa

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

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

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

From dholmes at openjdk.org  Tue Oct 14 05:40:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Oct 2025 05:40:01 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <gabbHqM7XDza_MsjQWTDUs-JeLr521xrM-Im3BGBi_c=.0c3f26ba-387e-437d-a804-f895a855e71c@github.com>

On Mon, 13 Oct 2025 22:26:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`.
> 
> Passes tier1 and tier2 (fastdebug).

Sorry for ping-ponging on the serviceability labeling. I'm not sure this is the right fix. The logic to return a value from `post_class_file_load_hook` was added way back in JDK 9 by [JDK-8171008](https://bugs.openjdk.org/browse/JDK-8171008) as part of the original AOT compiler effort. But at that time no changes were made to any of the callers to use the new return value! That means this aspect of the code is completely untested - and it is also completely undocumented.

I'd be more inclined to treat the `has_been_modified` aspect of `JvmtiClassFileLoadHookPoster` as dead code and remove it again. But we need serviceability folk to make that call - @plummercj or @sspitsyn ?

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

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3400196178

From aboldtch at openjdk.org  Tue Oct 14 05:43:16 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 05:43:16 GMT
Subject: RFR: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll
 in disallowed state [v3]
In-Reply-To: <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
 <iQGEZnxpFXQmtKwwYVFOaCkTz7kHcvpSBttyRO7Ylxs=.b0c898ff-32a8-4676-9612-3ca20664a514@github.com>
Message-ID: <1q85w7kQkDpro3hC5sLTIoKoiU2pMb-g8EJGTGyAnFQ=.971e83d7-7f59-42fe-be64-c9120f1ac530@github.com>

On Mon, 13 Oct 2025 08:32:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
>> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
>> 
>> Example stack trace:
>> 
>> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
>> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
>> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
>> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
>> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
>> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
>> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
>> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
>> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
>> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
>> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
>> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
>> 
>> 
>> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.
>
> Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check !cont.entry()->is_virtual_thread()

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27716#issuecomment-3400197550

From aboldtch at openjdk.org  Tue Oct 14 05:43:18 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 05:43:18 GMT
Subject: Integrated: 8369482: JVMTI + Loom: JDK-8368159 introduced safepoint
 poll in disallowed state
In-Reply-To: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
References: <2CSA7VYFmKJk5fY43g06HbHmDqnWOFd4jZUF1cHcVzw=.b77e7399-8d37-4a8c-a524-1da4c4fd31ab@github.com>
Message-ID: <KmzOzd8Okim8eeewadNah18gqYjbQtPjXS_7k0C_hnk=.a4fb1e24-7340-49c0-a50b-1815a7b1939e@github.com>

On Thu, 9 Oct 2025 08:05:27 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> [JDK-8368159](https://bugs.openjdk.org/browse/JDK-8368159) added `JvmtiExport::has_frame_pops(JavaThread* thread)`
> which calls `JvmtiExport::get_jvmti_thread_state();` which may safepoint.
> 
> Example stack trace:
> 
> V [libjvm.dylib+0x125f888] VMError::report(outputStream*, bool)+0x1b68 (javaThread.cpp:375)
> V [libjvm.dylib+0x1263184] VMError::report_and_die(int, char const*, char const*, char*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x55c
> V [libjvm.dylib+0x5de268] print_error_for_unit_test(char const*, char const*, char*)+0x0
> V [libjvm.dylib+0x9427ec] JavaThread::check_for_valid_safepoint_state()+0x120
> V [libjvm.dylib+0xe7e4e4] Mutex::lock(Thread*)+0x48
> V [libjvm.dylib+0xbbb198] JvmtiThreadState::state_for(JavaThread*, Handle)+0x200
> V [libjvm.dylib+0xc462ec] JvmtiEventControllerPrivate::thread_started(JavaThread*)+0x1a0
> V [libjvm.dylib+0xc493a4] JvmtiExport::get_jvmti_thread_state(JavaThread*, bool)+0xc0
> V [libjvm.dylib+0xc5078c] JvmtiExport::has_frame_pops(JavaThread*)+0x24
> V [libjvm.dylib+0x59c398] freeze_epilog(JavaThread*, ContinuationWrapper&, freeze_result)+0xf8
> V [libjvm.dylib+0x59b6e8] Config<(oop_kind)0, CardTableBarrierSet>::freeze(JavaThread*, long*)+0x6f4
> V [libjvm.dylib+0x59a4d4] int freeze<Config<(oop_kind)0, CardTableBarrierSet>>(JavaThread*, long*)+0x108
> 
> 
> I suggest we do double checked on `JvmtiExport::can_post_frame_pop()` and move the `ContinuationWrapper::SafepointOp` scope.

This pull request has now been integrated.

Changeset: 5bf1bab5
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Committer: Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5bf1bab5b3b7ebd2adbc0508e451d6f37580d3ce
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

8369482: JVMTI + Loom: JDK-8368159 introduced safepoint poll in disallowed state

Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Reviewed-by: sspitsyn, pchilanomate

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

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

From fandreuzzi at openjdk.org  Tue Oct 14 08:12:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 08:12:47 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
In-Reply-To: <bt2QtH0K1Aps2ed1ug0JUNpJ1KLCWOZOHJtL0dKrRNk=.8287a986-9a7a-4dde-9646-22b80c33a7f2@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <bt2QtH0K1Aps2ed1ug0JUNpJ1KLCWOZOHJtL0dKrRNk=.8287a986-9a7a-4dde-9646-22b80c33a7f2@github.com>
Message-ID: <R27ha-r4Rl-nFUgCRpKUzH17Ev0Rl50GbnMUvs1KDG4=.a392c37e-1edd-46a4-9983-6bd19a4d39f2@github.com>

On Mon, 13 Oct 2025 11:52:06 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> src/hotspot/share/prims/jvmtiAgentList.cpp line 201:
> 
>> 199:   if (JvmtiEnvBase::get_phase() != JVMTI_PHASE_LIVE) {
>> 200:     st->print_cr("Not in live phase");
>> 201:     return;
> 
> Will the agent be loaded later?

No, but the client can retry later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2426122346

From fandreuzzi at openjdk.org  Tue Oct 14 08:12:45 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 08:12:45 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
Message-ID: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>

In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.

Passes tier1 and tier2 (fastdebug).

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

Commit messages:
 - mv
 - nn
 - mv
 - fix check
 - macro
 - cc
 - nl
 - fix and test

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

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

From krk at openjdk.org  Tue Oct 14 08:12:46 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 14 Oct 2025 08:12:46 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <bt2QtH0K1Aps2ed1ug0JUNpJ1KLCWOZOHJtL0dKrRNk=.8287a986-9a7a-4dde-9646-22b80c33a7f2@github.com>

On Mon, 13 Oct 2025 11:26:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

src/hotspot/share/prims/jvmtiAgentList.cpp line 201:

> 199:   if (JvmtiEnvBase::get_phase() != JVMTI_PHASE_LIVE) {
> 200:     st->print_cr("Not in live phase");
> 201:     return;

Will the agent be loaded later?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2426112848

From fandreuzzi at openjdk.org  Tue Oct 14 08:17:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 14 Oct 2025 08:17:19 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  summary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/941f9a67..49722e1b

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

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

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

From rsunderbabu at openjdk.org  Tue Oct 14 10:51:37 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 14 Oct 2025 10:51:37 GMT
Subject: RFR: 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from
 problemlist
Message-ID: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>

vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java no longer fails with latest JDK. Probably GC got better during this time.
I tested with both -Xcomp and with -Xcomp -XX:UseZGC in latest builds. It was run for 100 iterations in all debug platforms. I was not able to reproduce the issue.
So, unproblemlisting this test to see if the issue still persists.

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

Commit messages:
 - 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from problemlist

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

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

From lmesnik at openjdk.org  Tue Oct 14 14:43:18 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 14 Oct 2025 14:43:18 GMT
Subject: RFR: 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from
 problemlist
In-Reply-To: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
References: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
Message-ID: <yoepSMWjsWHjKMNG88FRiGedYJt-mg1EAfRd5CJhimI=.6d760759-361c-4cfb-9df1-769618e93851@github.com>

On Tue, 14 Oct 2025 10:28:46 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java no longer fails with latest JDK. Probably GC got better during this time.
> I tested with both -Xcomp and with -Xcomp -XX:UseZGC in latest builds. It was run for 100 iterations in all debug platforms. I was not able to reproduce the issue.
> So, unproblemlisting this test to see if the issue still persists.

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27795#pullrequestreview-3336059985

From duke at openjdk.org  Tue Oct 14 14:51:47 2025
From: duke at openjdk.org (duke)
Date: Tue, 14 Oct 2025 14:51:47 GMT
Subject: RFR: 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from
 problemlist
In-Reply-To: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
References: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
Message-ID: <adWhXtg0wJdF15d-0HNAqjJqeBRZujLOJnFIq-wEr5U=.abfe01b0-8dec-46a4-a985-c1f10b12fc98@github.com>

On Tue, 14 Oct 2025 10:28:46 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java no longer fails with latest JDK. Probably GC got better during this time.
> I tested with both -Xcomp and with -Xcomp -XX:UseZGC in latest builds. It was run for 100 iterations in all debug platforms. I was not able to reproduce the issue.
> So, unproblemlisting this test to see if the issue still persists.

@rsunderbabu 
Your change (at version 7e36b5c504ca6883d6234dc1a51a1f13ea03b791) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27795#issuecomment-3402247193

From chagedorn at openjdk.org  Tue Oct 14 15:33:55 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 14 Oct 2025 15:33:55 GMT
Subject: RFR: 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from
 problemlist
In-Reply-To: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
References: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
Message-ID: <2nxhM1PC-jCLulC49lDokJuD8LxRaK77WiWHqawgUiE=.43cfd50c-34f2-4f2c-807f-db44323157f1@github.com>

On Tue, 14 Oct 2025 10:28:46 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java no longer fails with latest JDK. Probably GC got better during this time.
> I tested with both -Xcomp and with -Xcomp -XX:UseZGC in latest builds. It was run for 100 iterations in all debug platforms. I was not able to reproduce the issue.
> So, unproblemlisting this test to see if the issue still persists.

Looks good and trivial, thanks!

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

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27795#pullrequestreview-3336287075

From rsunderbabu at openjdk.org  Tue Oct 14 15:36:58 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 14 Oct 2025 15:36:58 GMT
Subject: Integrated: 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from
 problemlist
In-Reply-To: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
References: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
Message-ID: <PmkfsPEAi9gGDi71CjGadr2T4x2jYvOr_pbs8lMbX28=.1c5e47a5-2114-4c8a-85ba-9c607ac74f27@github.com>

On Tue, 14 Oct 2025 10:28:46 GMT, Ramkumar Sunderbabu <rsunderbabu at openjdk.org> wrote:

> vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java no longer fails with latest JDK. Probably GC got better during this time.
> I tested with both -Xcomp and with -Xcomp -XX:UseZGC in latest builds. It was run for 100 iterations in all debug platforms. I was not able to reproduce the issue.
> So, unproblemlisting this test to see if the issue still persists.

This pull request has now been integrated.

Changeset: 64ff7062
Author:    Ramkumar Sunderbabu <rsunderbabu at openjdk.org>
Committer: Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64ff7062c1cef13d16acddbcaf5401d7c2ad6dc0
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from problemlist

Reviewed-by: lmesnik, chagedorn

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

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

From rsunderbabu at openjdk.org  Tue Oct 14 16:15:10 2025
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Tue, 14 Oct 2025 16:15:10 GMT
Subject: RFR: 8369806: Remove nsk/jvmti/AttachOnDemand/attach020 from
 problemlist
In-Reply-To: <yoepSMWjsWHjKMNG88FRiGedYJt-mg1EAfRd5CJhimI=.6d760759-361c-4cfb-9df1-769618e93851@github.com>
References: <JLApxCfF3s0Tv6SeDuQM5Dtls1Qhr3m36xrbwYcr4XE=.cd1bab92-c89d-4447-835f-1ad4291e8d09@github.com>
 <yoepSMWjsWHjKMNG88FRiGedYJt-mg1EAfRd5CJhimI=.6d760759-361c-4cfb-9df1-769618e93851@github.com>
Message-ID: <dNVMrfsirBs1GEh4uqHwJKY89vS6_3SnksSvsN0vWVk=.19094e3e-d31b-43f6-84ae-7a43000b675a@github.com>

On Tue, 14 Oct 2025 14:41:00 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java no longer fails with latest JDK. Probably GC got better during this time.
>> I tested with both -Xcomp and with -Xcomp -XX:UseZGC in latest builds. It was run for 100 iterations in all debug platforms. I was not able to reproduce the issue.
>> So, unproblemlisting this test to see if the issue still persists.
>
> Marked as reviewed by lmesnik (Reviewer).

Thank you @lmesnik and @chhagedorn

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

PR Comment: https://git.openjdk.org/jdk/pull/27795#issuecomment-3402651731

From pchilanomate at openjdk.org  Tue Oct 14 18:14:34 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 18:14:34 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub
In-Reply-To: <invP6sQ5jfAy9_oncbxq9ZZNVzHLNJRe8hcyMwCy1E8=.637df4ab-3eed-41f6-af61-595b1af93be8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ImPuKKN1BMTV3XY0twNPZ-AWNGtqSWGhhleclAuMjHQ=.0ab40f78-1d95-40a7-93dc-f6c3e2dd3580@github.com>
 <invP6sQ5jfAy9_oncbxq9ZZNVzHLNJRe8hcyMwCy1E8=.637df4ab-3eed-41f6-af61-595b1af93be8@github.com>
Message-ID: <JNq9zeianmtdnAzbmuIwY43oih7DFmtKqluWS-jITyc=.17755a4e-3697-49e2-9df9-0703f112d4f9@github.com>

On Sat, 11 Oct 2025 05:09:31 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> > @plummercj Did you run `jhsdb jstack --mixed` ? StubRoutine would appear in mixed mode only I think (in Linux, at least).
> 
> I did not, and unfortunately --mixed is not support on OSX.
>
Ok, that?s why I wasn?t seeing `<StubRoutines (continuation stubs)>` either. I removed `?mixed` because it wasn?t working for me, only the top native frame was shown in the stacktrace (on linux-x64). I could still reproduce the assert without `?mixed` so I continued testing that way assuming the output for the `enterSpecial` frame would be the same in both modes. 
Now, testing on linux-aarch64, `?mixed` mode works and I can see `<StubRoutines (continuation stubs)>` for the `enterSpecial` frame. Looking at the code, I see the difference with mixed mode is the way we walk the stack. Even for Java frames the sender is always obtained through this method [1], relying basically on the FP. Then once we get to the frame with pc equal to the return barrier, here [2] we will just branch to the else case and print it as a continuation stub instead of the `enterSpecial` frame.
I was also curious how we can walk compiled frames this way, since the FP will not contain in general a valid link unless `-XX:+PreserveFramePointer` is set. So I added `-Xcomp` to `LingeredApp.startApp` and I see that we indeed fail to walk the stack:


----------------- 2943661 -----------------
"ForkJoinPool-1-worker-2" #30 daemon prio=5 tid=0x0000ffff08007f30 nid=2943661 runnable [0x0000ffff695e1000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x0000ffff9bb40b24	__clock_nanosleep + 0x84
0x0000ffff9bb45c0c	__GI___nanosleep + 0x1c
0x0000ffff9bb45acc	__sleep + 0x4c
0x0000ffff836fb338	<nep_invoker_blob>
0x0000ffff7c802ef8	* java.lang.invoke.LambdaForm$MH+0x0000000601047800.invoke(java.lang.Object, long, int) bci:10 (Compiled frame)
                  	* java.lang.invoke.LambdaForm$MH+0x000000060104d400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame)
0x910023e12a0003e2		????????
----------------- 2943659 -----------------


When setting` -XX:+PreserveFramePointer` we can walk them again (also tweaked the code to print the correct `enterSpecial` frame):


----------------- 2947348 -----------------
"ForkJoinPool-1-worker-2" #30 daemon prio=5 tid=0x0000ffff1c008040 nid=2947348 runnable [0x0000ffff7c8dd000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x0000ffffaee18b24	__clock_nanosleep + 0x84
0x0000ffffaee1dc0c	__GI___nanosleep + 0x1c
0x0000ffffaee1dacc	__sleep + 0x4c
0x0000ffff976faa38	<nep_invoker_blob>
0x0000ffff90806f3c	* java.lang.invoke.LambdaForm$MH+0x000007e001047800.invoke(java.lang.Object, long, int) bci:10 (Compiled frame)
0x0000ffff90bad354	* java.lang.invoke.LambdaForm$MH+0x000007e00104d400.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame)
0x0000ffff97597d60	* jdk.internal.foreign.abi.DowncallStub+0x000007e001048800.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x0000ffff908b7a70	* java.lang.invoke.LambdaForm$DMH+0x000007e001048c00.invokeStaticInit(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Compiled frame)
0x0000ffff90b9b710	* java.lang.invoke.LambdaForm$MH+0x000007e00104c800.invoke(java.lang.Object, int) bci:44 (Compiled frame)
0x0000ffff90b9041c	* java.lang.invoke.LambdaForm$MH+0x000007e00104c400.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Compiled frame)
0x0000ffff97597f30	* LingeredAppWithVirtualThread.run() bci:15 line:65 (Interpreted frame)
0x0000ffff975963b8	* jdk.internal.vm.Continuation.enterSpecial(jdk.internal.vm.Continuation, boolean, boolean) bci:0 (Compiled frame)
0x0000ffff97fa5fbc	* jdk.internal.vm.Continuation.run() bci:152 line:251 (Compiled frame)
0x0000ffff90b85888	* java.lang.VirtualThread.runContinuation() bci:100 line:293 (Compiled frame)
0x0000ffff97fa3eb0	* java.lang.VirtualThread$$Lambda+0x000007e001034c88.run() bci:4 (Compiled frame)
0x0000ffff90b8445c	* java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec() bci:4 line:1596 (Compiled frame)
0x0000ffff90b83298	* java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Compiled frame)
0x0000ffff90b81e2c	* java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Compiled frame)
                  	* java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Compiled frame)
0x0000ffff97fa03a8	* java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Compiled frame)
0x0000ffff9759349c	<StubRoutines (initial stubs)>
0x0000ffffad95020c	JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x45c
0x0000ffffad950880	JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x278
0x0000ffffad950e14	JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0x8c
0x0000ffffadaee66c	thread_entry(JavaThread*, JavaThread*) + 0xc4
0x0000ffffad98de68	JavaThread::thread_main_inner() + 0x108
0x0000ffffae301efc	Thread::call_run() + 0xac
0x0000ffffadfe105c	thread_native_entry(Thread*) + 0x12c
0x0000ffffaede3b50	start_thread + 0x300

I would have expected that `mixed` mode walked the stack similar to how we do it in the VM with `NativeStackPrinter` using `frame::next_frame()`, i.e we change how we get the sender based on the frame.

Anyways, I was just curious about the difference in output with `mixed` mode.

[1] https://github.com/openjdk/jdk/blob/d6537c6d3ee6d7a59d609b277f0538da0afb0fbf/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/linux/aarch64/LinuxAARCH64CFrame.java#L56
[2] https://github.com/openjdk/jdk/blob/d6537c6d3ee6d7a59d609b277f0538da0afb0fbf/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java#L148

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3403057882

From pchilanomate at openjdk.org  Tue Oct 14 18:18:47 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 14 Oct 2025 18:18:47 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v9]
In-Reply-To: <GnJa0HsJtd4nsyhs3ltDLl2wwuoOUgvsLRjOSyrdQwU=.f627322c-dc7b-4422-8192-e0981fbdf94b@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <GnJa0HsJtd4nsyhs3ltDLl2wwuoOUgvsLRjOSyrdQwU=.f627322c-dc7b-4422-8192-e0981fbdf94b@github.com>
Message-ID: <n2Bdvt41BJIol1YFGlYEXkRTI1UTRnDC_2DOL5gkRcg=.fc70458d-2fb8-4476-b673-f29976512e5e@github.com>

On Tue, 14 Oct 2025 05:27:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TestJhsdbJstackWithVirtualThread.java

test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java line 67:

> 65:     public void run() {
> 66:         signal.countDown();
> 67:         Thread.yield();

`Thread.yield` should be moved before the `countDown` call, unless you intentionally want to make it time-dependent and catch the target at possibly different stages (before/after unmounting).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2430051397

From liach at openjdk.org  Tue Oct 14 23:12:34 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 14 Oct 2025 23:12:34 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

Chen Liang 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 16 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Ioi review
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
 - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
   
   Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
 - Variable name improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
 - ... and 6 more: https://git.openjdk.org/jdk/compare/336f1cad...25972f2d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/a659f538..25972f2d

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

  Stats: 244224 lines in 3760 files changed: 182111 ins; 40283 del; 21830 mod
  Patch: https://git.openjdk.org/jdk/pull/25124.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25124/head:pull/25124

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

From duke at openjdk.org  Tue Oct 14 23:44:12 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 14 Oct 2025 23:44:12 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
Message-ID: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>

[JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)

Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)

`DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`

`StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions

`NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC

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

Commit messages:
 - Fix tests

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

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

From duke at openjdk.org  Tue Oct 14 23:44:13 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 14 Oct 2025 23:44:13 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
Message-ID: <v-VXHMPkKaS1eX-ykYKSw0sSiPJQ-DEQnoGKIYQFv20=.2ef5d122-beb9-486b-a753-0d6d82c316f8@github.com>

On Mon, 6 Oct 2025 20:13:46 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
> 
> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
> 
> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
> 
> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
> 
> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC

@vnkozlov Could you provide your configure and more test output for https://bugs.openjdk.org/browse/JDK-8369150

I'm not able to reproduce

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3373861196

From duke at openjdk.org  Tue Oct 14 23:47:00 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 14 Oct 2025 23:47:00 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
Message-ID: <-Lv9OC8lY8jwMPZ0HxA1DUWoa611YLmOKM7JQmv0mpc=.607ec490-a9af-45b2-9a23-aa64a82d40c0@github.com>

On Mon, 6 Oct 2025 20:13:46 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
> 
> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
> 
> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
> 
> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
> 
> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC

The following occurs when running DeoptimizeRelocatedNMethod on PPC64

#  Internal Error (jdk/src/hotspot/cpu/ppc/nativeInst_ppc.cpp:405)
#  assert(!decode(i1, i2)) failed: already patched

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x1701784]  NativePostCallNop::patch(int, int)+0xf4  (nativeInst_ppc.cpp:405)
V  [libjvm.so+0x1718414]  nmethod::finalize_relocations()+0x6f4  (nmethod.cpp:2059)
V  [libjvm.so+0x171891c]  nmethod::post_init()+0x5c  (nmethod.cpp:1252)
V  [libjvm.so+0x171a8dc]  nmethod::relocate(CodeBlobType)+0x1ec  (nmethod.cpp:1515)
V  [libjvm.so+0x200b598]  WB_RelocateNMethodFromMethod+0x388  (whitebox.cpp:1653)
j  jdk.test.whitebox.WhiteBox.relocateNMethodFromMethod0(Ljava/lang/reflect/Executable;I)V+0
j  jdk.test.whitebox.WhiteBox.relocateNMethodFromMethod(Ljava/lang/reflect/Executable;I)V+8
j  compiler.whitebox.DeoptimizeRelocatedNMethod.main([Ljava/lang/String;)V+50


@TheRealMDoerr @reinrich Do you have any ideas on a solution for this? I don't have any experience working with PPC so guidance would be greatly appreciated

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3403992989

From ysuenaga at openjdk.org  Wed Oct 15 00:53:17 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 15 Oct 2025 00:53:17 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v9]
In-Reply-To: <GnJa0HsJtd4nsyhs3ltDLl2wwuoOUgvsLRjOSyrdQwU=.f627322c-dc7b-4422-8192-e0981fbdf94b@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <GnJa0HsJtd4nsyhs3ltDLl2wwuoOUgvsLRjOSyrdQwU=.f627322c-dc7b-4422-8192-e0981fbdf94b@github.com>
Message-ID: <KUqlaqAbE-E0NkNEXbJbiy_GoejA-VISYNzhNdPTQn0=.d434760b-3bca-4826-84cf-994db371d990@github.com>

On Tue, 14 Oct 2025 05:27:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update TestJhsdbJstackWithVirtualThread.java

I guess `jhsdb jstack --mixed` might have potential bug(s) in `-Xcomp` regardless of continuation stub handling.

I ran `jhsdb jstack --mixed` with this PR to attach to the process running with `-Xcomp` on Linux x86_64, I got similar strange stack traces (without error) as following. It seems not to unwind completely in `-Xcomp`. LWP 1332 was failed to find sender frame from 0x7f9debcd96c0, LWP 1331 and 1330 are not compiled frame, but they couldn't find sender frame (maybe stack unwinder in jhsdb decide to stop unwinding because sender frame is NULL).


----------------- 1332 -----------------
"ForkJoinPool-1-worker-2" #29 daemon prio=5 tid=0x00007f9dfc2ad7b0 nid=1332 runnable [0x00007f9dd19fd000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007f9e0337e462      __syscall_cancel_arch + 0x32
0x00007f9e0337275c      __internal_syscall_cancel + 0x5c
0x00007f9e033cec37      __GI___nanosleep + 0x17
0x00007f9e033e114e      __sleep + 0x3e
0x00007f9deb4b361e      <nep_invoker_blob>
0x00007f9debcd96c0      * java.lang.invoke.LambdaForm$MH+0x000000000f047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame)
0x8b486428ec834853              ????????
----------------- 1331 -----------------
"ForkJoinPool-1-worker-1" #27 daemon prio=5 tid=0x00007f9dfc2ac5b0 nid=1331 runnable [0x00007f9dd1afd000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007f9e0337e462      __syscall_cancel_arch + 0x32
0x00007f9e0337275c      __internal_syscall_cancel + 0x5c
0x00007f9e033cec37      __GI___nanosleep + 0x17
0x00007f9e033e114e      __sleep + 0x3e
0x00007f9deb4b361e      <nep_invoker_blob>
0x00007f9de45d5c2c      * java.lang.invoke.LambdaForm$MH+0x000000000f047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame)
                        * java.lang.invoke.LambdaForm$MH+0x000000000f04f000.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame)
                        * jdk.internal.foreign.abi.DowncallStub+0x000000000f048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
----------------- 1330 -----------------
"VirtualThread-unblocker" #25 daemon prio=5 tid=0x00007f9dfc297b50 nid=1330 runnable [0x00007f9dd1bfd000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007f9e0337e462      __syscall_cancel_arch + 0x32
0x00007f9e0337275c      __internal_syscall_cancel + 0x5c
0x00007f9e0337549e      __GI___pthread_cond_wait + 0x14e
0x00007f9e01f0d834      PlatformEvent::park() + 0xe4
0x00007f9e019889ca      JVM_TakeVirtualThreadListToUnblock + 0x1ba
0x00007f9debc9cc16      java.lang.VirtualThread.takeVirtualThreadListToUnblock() + 0x96 (Native method)


In addition, I saw following error when I added both `-Xcomp` and `-XX:+PreserveFramePointer` in Linux x86_64. Note that I haven't seen this with `-XX:+PreserveFramePointer` only.


java.lang.RuntimeException: newSP(0x00007f345cb14690) is not above oldSP(0x00007f345cb14690)
        at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:156)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
        at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
        at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)


----------------- 1425 -----------------
"ForkJoinPool-1-worker-4" #33 daemon prio=5 tid=0x00007f34782bac50 nid=1425 runnable [0x00007f345ca14000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007f3482592462      __syscall_cancel_arch + 0x32
0x00007f348258675c      __internal_syscall_cancel + 0x5c
0x00007f34825e2c37      __GI___nanosleep + 0x17
0x00007f34825f514e      __sleep + 0x3e
0x00007f34673a899e      <nep_invoker_blob>
0x00007f3467ce4d44      * java.lang.invoke.LambdaForm$MH+0x0000000034047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame)
0x00007f3467ce5094      * java.lang.invoke.LambdaForm$MH+0x000000003404e800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame)
0x00007f346733fe48      * jdk.internal.foreign.abi.DowncallStub+0x0000000034048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x00007f3460674744      * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Compiled frame)
0x00007f3460739944      * java.lang.invoke.LambdaForm$MH+0x000000003404c800.invoke(java.lang.Object, int) bci:44 (Compiled frame)
0x00007f346072f3ac      * java.lang.invoke.LambdaForm$MH+0x000000003404b800.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Compiled frame)
0x00007f346733fd00      * Test.run() bci:9 line:40 (Interpreted frame)
0x00007f346733e098      <StubRoutines (continuation stubs)>
0x00007f3467cbeb50      * jdk.internal.vm.Continuation.run() bci:152 line:251 (Compiled frame)
0x00007f3467cd0eb8      * java.lang.VirtualThread.runContinuation() bci:100 line:293 (Compiled frame)
0x00007f3467cbbf40      * java.lang.VirtualThread$$Lambda+0x000000003402a848.run() bci:4 (Compiled frame)
0x00007f3467cd13e8      * java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec() bci:4 line:1596 (Compiled frame)
0x00007f3467cd01e0      * java.util.concurrent.ForkJoinTask.doExec() bci:10 line:511 (Compiled frame)
                        * java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(java.util.concurrent.ForkJoinTask, int) bci:5 line:1450 (Compiled frame)
0x00007f346733fd00      * java.util.concurrent.ForkJoinPool.runWorker(java.util.concurrent.ForkJoinPool$WorkQueue) bci:364 line:2019 (Interpreted frame)
0x00007f3467cb6b04      * java.util.concurrent.ForkJoinWorkerThread.run() bci:31 line:187 (Compiled frame)
0x00007f34673386fd      <StubRoutines (initial stubs)>
0x00007f34809c0a7e      JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007f34809c11b3      JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007f34809c17bb      JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007f3480b83a90      thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007f3480a02806      JavaThread::thread_main_inner() + 0x256
0x00007f3481665b57      Thread::call_run() + 0xb7
0x00007f34810fc588      thread_native_entry(Thread*) + 0x128
0x00007f3482589f54      start_thread + 0x2e4

----------------- 1424 -----------------
"ForkJoinPool-1-worker-3" #31 daemon prio=5 tid=0x00007f34782b6d00 nid=1424 runnable [0x00007f345cb14000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007f3482592462      __syscall_cancel_arch + 0x32
0x00007f348258675c      __internal_syscall_cancel + 0x5c
0x00007f34825e2c37      __GI___nanosleep + 0x17
0x00007f34825f514e      __sleep + 0x3e
0x00007f34673a899e      <nep_invoker_blob>
0x00007f3467ce4d44      * java.lang.invoke.LambdaForm$MH+0x0000000034047000.invoke(java.lang.Object, long, int) bci:10 (Compiled frame)
0x00007f346074ed84      * java.lang.invoke.LambdaForm$MH+0x000000003404e800.invokeExact_MT(java.lang.Object, long, int, java.lang.Object) bci:21 (Compiled frame)
0x00007f346733fe48      * jdk.internal.foreign.abi.DowncallStub+0x0000000034048000.invoke(java.lang.foreign.SegmentAllocator, java.lang.foreign.MemorySegment, int) bci:44 (Interpreted frame)
0x00007f3467cda978      * java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.lang.Object, java.lang.Object, java.lang.Object, int) bci:14 (Compiled frame)
0x00007f3467cd9118      * java.lang.invoke.LambdaForm$MH+0x000000003404d000.invoke(java.lang.Object, int) bci:44 (Compiled frame)
0x00007f3467cd5c94      * java.lang.invoke.LambdaForm$MH+0x000000003404b800.invoke_MT(java.lang.Object, int, java.lang.Object) bci:18 (Compiled frame)
0x00007f34607129fc      * Test.run() bci:9 line:40 (Compiled frame)
0x00007f346733e098      <StubRoutines (continuation stubs)>
0x00007f3467cbeb50      <Unknown compiled code>
0x00007f3467cd0eb8      <Unknown compiled code>
0x00007f3467cbbf40      <Unknown compiled code>
0x00007f3460726924      <Unknown compiled code>
0x00007f3460723b24      <Unknown compiled code>
0x00007f346733fd00      <interpreter> return entry points
0x00007f3467cb6b04      <Unknown compiled code>
0x00007f34673386fd      <StubRoutines (initial stubs)>
0x00007f34809c0a7e      JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007f34809c11b3      JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007f34809c17bb      JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007f3480b83a90      thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007f3480a02806      JavaThread::thread_main_inner() + 0x256
0x00007f3481665b57      Thread::call_run() + 0xb7
0x00007f34810fc588      thread_native_entry(Thread*) + 0x128
0x00007f3482589f54      start_thread + 0x2e4


This is a problem in restoring Java frame, not native frame - native frame unwinding depends on DWARF in Linux x86_64, on FP ( `X29` ) in AArch64. Thus we might need to fix unwinder for Java frames. But it is another issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3404126783

From ysuenaga at openjdk.org  Wed Oct 15 01:03:57 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 15 Oct 2025 01:03:57 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v10]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <jmNdm5tXqFoNyhhnxwepAtm5xEO2R1j6PDxyEhvczgg=.4385855f-774d-4216-b5ff-4841f74b5492@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Move Thread.yield()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/b82bb9aa..e64d696b

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

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

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

From cjplummer at openjdk.org  Wed Oct 15 03:03:03 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 Oct 2025 03:03:03 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v10]
In-Reply-To: <jmNdm5tXqFoNyhhnxwepAtm5xEO2R1j6PDxyEhvczgg=.4385855f-774d-4216-b5ff-4841f74b5492@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <jmNdm5tXqFoNyhhnxwepAtm5xEO2R1j6PDxyEhvczgg=.4385855f-774d-4216-b5ff-4841f74b5492@github.com>
Message-ID: <RniozVV4kFg0G2eSRqc9tJZyRfE2pd-OW6eXujhNStE=.4bc1266e-54a4-418f-a6ff-e9e5d79c05ee@github.com>

On Wed, 15 Oct 2025 01:03:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move Thread.yield()

The changes look good. Thanks for taking care of this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3338179214

From sspitsyn at openjdk.org  Wed Oct 15 06:09:16 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 06:09:16 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
Message-ID: <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>

On Tue, 14 Oct 2025 23:12:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang 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 16 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Ioi review
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
>  - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Variable name improvements
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e7527539...25972f2d

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:

> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
> 94:                         // Remove dummy field

Q: Is this dummy field removed or added? Seems to be a mismatch between the comment and the real action.

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 102:

> 100:     // Extracts ClassVersion values from the provided class bytes.
> 101:     private static int getClassBytesVersion(byte[] classBytes) {
> 102:         ClassModel clazz = ClassFile.of().parse(classBytes);

Nit: Better to make it consistent with the case below and call it `classModel` instead of `clazz`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2431212827
PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2431217408

From sspitsyn at openjdk.org  Wed Oct 15 06:09:17 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 06:09:17 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
 <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
Message-ID: <YhG4F1UYY6fAnKDDQ96AgMA76qah89ew1ZNER3_ctEE=.234eca17-5377-431b-a11c-59765da9838f@github.com>

On Wed, 15 Oct 2025 06:03:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chen Liang 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 16 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Ioi review
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
>>  - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Variable name improvements
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e7527539...25972f2d
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/RedefineRetransform.java line 102:
> 
>> 100:     // Extracts ClassVersion values from the provided class bytes.
>> 101:     private static int getClassBytesVersion(byte[] classBytes) {
>> 102:         ClassModel clazz = ClassFile.of().parse(classBytes);
> 
> Nit: Better to make it consistent with the case below and call it `classModel` instead of `clazz`.

BTW, thank you for previous re-naming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2431221860

From sspitsyn at openjdk.org  Wed Oct 15 06:22:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 06:22:05 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <dyIc3CzGD5R2y4ZGa0TtOKxdgpLqkeJcQwsyAGySEg4=.155c31e7-94e4-4950-b935-c17c38f3a6ab@github.com>

On Mon, 13 Oct 2025 22:26:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`.
> 
> Passes tier1 and tier2 (fastdebug).

David posted:
> I'd be more inclined to treat the has_been_modified aspect of JvmtiClassFileLoadHookPoster as dead code and remove it again. But we need serviceability folk to make that call - @plummercj or @sspitsyn ?

I agree with David. It is better to treat the the `has_been_modified` aspect of `JvmtiClassFileLoadHookPoster` as dead code and remove it again.

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

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3404733969

From rrich at openjdk.org  Wed Oct 15 07:03:37 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 15 Oct 2025 07:03:37 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <-Lv9OC8lY8jwMPZ0HxA1DUWoa611YLmOKM7JQmv0mpc=.607ec490-a9af-45b2-9a23-aa64a82d40c0@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <-Lv9OC8lY8jwMPZ0HxA1DUWoa611YLmOKM7JQmv0mpc=.607ec490-a9af-45b2-9a23-aa64a82d40c0@github.com>
Message-ID: <_Qq4FsgAKYZ3OOy3TqcUusIS-wwp2r0bVdMRA8P_yQg=.544f2edd-5e99-489b-923e-07d69a2de407@github.com>

On Tue, 14 Oct 2025 23:44:39 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> The following occurs when running DeoptimizeRelocatedNMethod on PPC64
> 
> ```
> #  Internal Error (jdk/src/hotspot/cpu/ppc/nativeInst_ppc.cpp:405)
> #  assert(!decode(i1, i2)) failed: already patched
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1701784]  NativePostCallNop::patch(int, int)+0xf4  (nativeInst_ppc.cpp:405)
> V  [libjvm.so+0x1718414]  nmethod::finalize_relocations()+0x6f4  (nmethod.cpp:2059)
> V  [libjvm.so+0x171891c]  nmethod::post_init()+0x5c  (nmethod.cpp:1252)
> V  [libjvm.so+0x171a8dc]  nmethod::relocate(CodeBlobType)+0x1ec  (nmethod.cpp:1515)
> V  [libjvm.so+0x200b598]  WB_RelocateNMethodFromMethod+0x388  (whitebox.cpp:1653)
> j  jdk.test.whitebox.WhiteBox.relocateNMethodFromMethod0(Ljava/lang/reflect/Executable;I)V+0
> j  jdk.test.whitebox.WhiteBox.relocateNMethodFromMethod(Ljava/lang/reflect/Executable;I)V+8
> j  compiler.whitebox.DeoptimizeRelocatedNMethod.main([Ljava/lang/String;)V+50
> ```
> 
> @TheRealMDoerr @reinrich Do you have any ideas on a solution for this? I don't have any experience working with PPC so guidance would be greatly appreciated

It's fixed with https://bugs.openjdk.org/browse/JDK-8369257

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3404874700

From fandreuzzi at openjdk.org  Wed Oct 15 08:57:56 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 08:57:56 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>

> `JvmtiExport::post_class_file_load_hook` returns a boolean, which tells whether the hook modified the class data or not. Users of the function write the same check on their own. I propose replacing the handwritten check with the boolean returned by `post_class_file_load_hook`.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - remove dead code
 - revert
 - Merge branch 'master' into JDK-8369734
 - use

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27777/files
  - new: https://git.openjdk.org/jdk/pull/27777/files/ad416a98..8fbf7599

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

  Stats: 5110 lines in 177 files changed: 1555 ins; 3254 del; 301 mod
  Patch: https://git.openjdk.org/jdk/pull/27777.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27777/head:pull/27777

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

From fandreuzzi at openjdk.org  Wed Oct 15 09:00:03 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 09:00:03 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used
In-Reply-To: <gabbHqM7XDza_MsjQWTDUs-JeLr521xrM-Im3BGBi_c=.0c3f26ba-387e-437d-a804-f895a855e71c@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <gabbHqM7XDza_MsjQWTDUs-JeLr521xrM-Im3BGBi_c=.0c3f26ba-387e-437d-a804-f895a855e71c@github.com>
Message-ID: <7bwGb0-sxPKYEcK7XXUa9XiPjeft5hUAsh_fX2VFTVI=.67b62c75-c78f-4d3c-8b9a-de63f213c2b9@github.com>

On Tue, 14 Oct 2025 05:37:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Sorry for ping-ponging on the serviceability labeling. I'm not sure this is the right fix. The logic to return a value from `post_class_file_load_hook` was added way back in JDK 9 by [JDK-8171008](https://bugs.openjdk.org/browse/JDK-8171008) as part of the original AOT compiler effort. But at that time no changes were made to any of the callers to use the new return value! That means this aspect of the code is completely untested - and it is also completely undocumented.
> 
> I'd be more inclined to treat the `has_been_modified` aspect of `JvmtiClassFileLoadHookPoster` as dead code and remove it again. But we need serviceability folk to make that call - @plummercj or @sspitsyn ?

Thanks for the feedback @dholmes-ora and @sspitsyn, I removed the dead code in 8fbf759.

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

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3405308607

From aturbanov at openjdk.org  Wed Oct 15 09:17:01 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 15 Oct 2025 09:17:01 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v10]
In-Reply-To: <jmNdm5tXqFoNyhhnxwepAtm5xEO2R1j6PDxyEhvczgg=.4385855f-774d-4216-b5ff-4841f74b5492@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <jmNdm5tXqFoNyhhnxwepAtm5xEO2R1j6PDxyEhvczgg=.4385855f-774d-4216-b5ff-4841f74b5492@github.com>
Message-ID: <9VZzFn1G5rtO1imn3pPRMNN4MoCq6VXkCMkrzuXwTGc=.3a248323-d912-4fef-853f-128d028d1266@github.com>

On Wed, 15 Oct 2025 01:03:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move Thread.yield()

test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java line 70:

> 68:         try {
> 69:             hndSleep.invoke(sleepArg);
> 70:         } catch(Throwable t) {

Suggestion:

        } catch (Throwable t) {

test/hotspot/jtreg/serviceability/sa/LingeredAppWithVirtualThread.java line 83:

> 81:             signal.await();
> 82:             LingeredApp.main(args);
> 83:         } catch(Exception e) {

Suggestion:

        } catch (Exception e) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2431780907
PR Review Comment: https://git.openjdk.org/jdk/pull/27728#discussion_r2431781235

From mdoerr at openjdk.org  Wed Oct 15 09:22:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Oct 2025 09:22:53 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <6-SGkLGIijJHm6qmQ8ro-SX9sFIEumElgIsyR2w4aJE=.64499300-2d0d-4cec-a98f-76af77f49cc6@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

I've rerun tests and haven't seen any issues on SAP supported platforms (including linux and AIX on PPC64).

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3405412507

From fandreuzzi at openjdk.org  Wed Oct 15 09:32:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 09:32:19 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v3]
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>

> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  don't return

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27777/files
  - new: https://git.openjdk.org/jdk/pull/27777/files/8fbf7599..8f7f0feb

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

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

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

From fandreuzzi at openjdk.org  Wed Oct 15 09:32:22 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 09:32:22 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
Message-ID: <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>

On Wed, 15 Oct 2025 08:57:56 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - remove dead code
>  - revert
>  - Merge branch 'master' into JDK-8369734
>  - use

Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?

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

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3405455797

From sspitsyn at openjdk.org  Wed Oct 15 09:27:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 09:27:41 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
Message-ID: <gS-j63ZrX4rTb9cGfUAuEHH6YB0st1S16AjB59pGcGU=.7788359b-dbaa-4701-8429-4acdee0a9364@github.com>

On Wed, 15 Oct 2025 08:57:56 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - remove dead code
>  - revert
>  - Merge branch 'master' into JDK-8369734
>  - use

Thank you for taking care about this and update!
Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3339340217

From kevinw at openjdk.org  Wed Oct 15 09:39:48 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 09:39:48 GMT
Subject: RFR: 8369894: Remove
 javax/management/remote/mandatory/loading/RMIDownloadTest.java from
 problemlist
Message-ID: <NqEEtu6PWJUORs5P5Q5SVouAREdnqLVBHFKcAwBtxGk=.c43c7862-23d5-4592-8ff9-751af8b65322@github.com>

This test was probemlisted, like several tests that were occasionally hanging on Windows when used with virtual threads.

This test looks reliable now. Key change may have been JDK-8282726.

Trivially remove from problem list.

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

Commit messages:
 - 8369894: Remove javax/management/remote/mandatory/loading/RMIDownloadTest.java from problemlist

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

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

From kevinw at openjdk.org  Wed Oct 15 10:08:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 10:08:23 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <MVJQcBy20VCW_1d6FPkMG_o4OnH_z5GpEio-LvSqfJk=.8c300a68-6295-411e-94a2-7b7188d3cafd@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

A possible more generic api doc:


    /**
     * Returns the CPU time used by garbage collection.
     *
     * <p> This is the CPU time used by all garbage collection activity, 
	 * including any overhead, which means the result may be non-zero 
	 * even if no GC has occurred. 
	 *
	 * This method may return {@code -1} if the
     * platform does not support this operation or the information is not available at any time.
	 *
     * @implNote Reported time will include relevant implementation-specific details such as
	 * driver threads, workers, VM Operations and string deduplication (if enabled). 
	 * This method will return -1 if called during shutdown.
     *
	 * @return the total accumulated CPU time for garbage collection
     * in nanoseconds, or -1
     * 
     * @since 26
     */
	 public long getTotalGcCpuTime();

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3405609355

From kevinw at openjdk.org  Wed Oct 15 10:17:35 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 10:17:35 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Or:


     * @implNote Time calculation is implementation-specific, and may include details
	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3405648131

From ysuenaga at openjdk.org  Wed Oct 15 10:27:24 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 15 Oct 2025 10:27:24 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11]
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <ZvpsjEeOR_SbhXSPsP0boc7YImT_gokILJgISm4PocA=.f27f8b76-5dc8-4a44-82c4-6876dfe2299f@github.com>

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Cosmetic change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27728/files
  - new: https://git.openjdk.org/jdk/pull/27728/files/e64d696b..a8e3f4f4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27728&range=09-10

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

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

From dholmes at openjdk.org  Wed Oct 15 12:40:00 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 15 Oct 2025 12:40:00 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v3]
In-Reply-To: <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>
Message-ID: <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com>

On Wed, 15 Oct 2025 09:32:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   don't return

LGTM. Thanks

src/hotspot/share/prims/jvmtiExport.cpp line 985:

> 983:     }
> 984:     if (new_data != nullptr) {
> 985:       // this agent has modified class data.

The comment could stay.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3340151397
PR Review Comment: https://git.openjdk.org/jdk/pull/27777#discussion_r2432392717

From fandreuzzi at openjdk.org  Wed Oct 15 13:52:11 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 13:52:11 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>

> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  restore comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27777/files
  - new: https://git.openjdk.org/jdk/pull/27777/files/8f7f0feb..37817420

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

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

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

From fandreuzzi at openjdk.org  Wed Oct 15 13:52:13 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 13:52:13 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <KFfbsj1X2ENz_qAZpL_s-RiBssDgEbOWmajS21u-M3A=.573b69d5-2d9c-440d-8088-6b6ae2b30377@github.com>
 <5jVlkIKu_yk8GnTLeWO6mkPC-pXHCaSn2l7LXFBJV9o=.bc7678f1-c9e2-494e-b0d0-4790aa9a31f9@github.com>
Message-ID: <8ofLOCG9laKHDsIkzUfXzP8om2uYZ8ouWT72U5gXI5s=.cbffb1ba-244b-4fbb-ad2e-cf036613422d@github.com>

On Wed, 15 Oct 2025 12:35:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   restore comment
>
> src/hotspot/share/prims/jvmtiExport.cpp line 985:
> 
>> 983:     }
>> 984:     if (new_data != nullptr) {
>> 985:       // this agent has modified class data.
> 
> The comment could stay.

378174203615473d5216cc67fbde50933c3c1c87

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27777#discussion_r2432637267

From alanb at openjdk.org  Wed Oct 15 13:59:27 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 15 Oct 2025 13:59:27 GMT
Subject: RFR: 8369894: Remove
 javax/management/remote/mandatory/loading/RMIDownloadTest.java from
 problemlist
In-Reply-To: <NqEEtu6PWJUORs5P5Q5SVouAREdnqLVBHFKcAwBtxGk=.c43c7862-23d5-4592-8ff9-751af8b65322@github.com>
References: <NqEEtu6PWJUORs5P5Q5SVouAREdnqLVBHFKcAwBtxGk=.c43c7862-23d5-4592-8ff9-751af8b65322@github.com>
Message-ID: <ixCU9PB2OY0UTJGVDTg2j0nu7HhSswgpbIsc_fm6PHI=.bde89f58-3f07-40b5-8a5b-95af365d70b8@github.com>

On Wed, 15 Oct 2025 09:32:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted, like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now. Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

Marked as reviewed by alanb (Reviewer).

This was likely JDK-8282726 so removing it from the exclude list is okay. I assume you've run it many times to make sure it is stable.

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

PR Review: https://git.openjdk.org/jdk/pull/27820#pullrequestreview-3340551860
PR Comment: https://git.openjdk.org/jdk/pull/27820#issuecomment-3406574825

From mdoerr at openjdk.org  Wed Oct 15 14:03:14 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 15 Oct 2025 14:03:14 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

One probably related issue on linuxaarch64 while testing "gc/epsilon/TestObjects.java":
SIGSEGV in caller_is_deopted:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x5531b8]  caller_is_deopted(JavaThread*)+0x2f8  (nativeInst_aarch64.hpp:536)
V  [libjvm.so+0x555000]  Runtime1::move_mirror_patching(JavaThread*)+0x20  (c1_Runtime1.cpp:1400)
v  ~RuntimeStub::C1 Runtime load_mirror_patching_blob 0x0000f7cf038f316c



R0 =0x00000000f001cee8 is an oop: java.util.HashMap 
{0x00000000f001cee8} - klass: 'java/util/HashMap' - flags: is_cloneable_fast 
 - ---- fields (total size 5 words):
 - transient 'keySet' 'Ljava/util/Set;' @8  null (0x00000000)
 - transient 'values' 'Ljava/util/Collection;' @12  null (0x00000000)
 - transient 'table' '[Ljava/util/HashMap$Node;' @16  a 'java/util/HashMap$Node'[128] {0x00000000f001cf10} (0xf001cf10)
 - transient 'entrySet' 'Ljava/util/Set;' @20  null (0x00000000)
 - transient 'size' 'I' @24  60 (0x0000003c)
 - transient 'modCount' 'I' @28  60 (0x0000003c)
 - 'threshold' 'I' @32  96 (0x00000060)
 - final 'loadFactor' 'F' @36  0.750000 (0x3f400000)
R1 =0x0000001fd503201f is an unknown value
R2 =0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
Compiled method (c1) 5966 2946       1       java.util.HashMap::values (25 bytes)
 total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
 main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
 stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
 mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
 relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
 metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
 immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
 dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
 scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
 scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
 speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
--------------------------------------------------------------------------------
  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
--------------------------------------------------------------------------------
R3 =0x0000f7cf03817578 points into unknown readable memory: 0x0000000000000000 | 00 00 00 00 00 00 00 00
R4 =0x0000f7cf038f3040 points into unknown readable memory: 0x0000000100000008 | 08 00 00 00 01 00 00 00
R5 =0x0000f7cf14430000 points into unknown readable memory: 0x0706050403020100 | 00 01 02 03 04 05 06 07
R6 =0x0000000000000006 is an unknown value
R7 =0x000000000000016c is an unknown value
R8 =0x0000f7cf1484ca18 is pointing into the stack for thread: 0x0000f7cf100305c0
R9 =0x0 is null
R10=0x0000f7cf1484c140 is pointing into the stack for thread: 0x0000f7cf100305c0
R11=0x000000000000003d is an unknown value
R12=0x000000000000003c is an unknown value
R13=0x0000f7cf1484ca60 is pointing into the stack for thread: 0x0000f7cf100305c0
R14=0x0000000000000008 is an unknown value
R15=0x0000f7cf15ef5ed9: <offset 0x00000000015c5ed9> in /testee-vm/lib/server/libjvm.so at 0x0000f7cf14930000
R16=0x0000000000000001 is an unknown value
R17=0x0000f7cf1602a6f4: __pthread_mutex_unlock+0x0000000000000000 in /lib/aarch64-linux-gnu/libc.so.6 at 0x0000f7cf15fa0000
R18=0x0000f7cf15ef5e01: <offset 0x00000000015c5e01> in /testee-vm/lib/server/libjvm.so at 0x0000f7cf14930000
R19=0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
Compiled method (c1) 5973 2946       1       java.util.HashMap::values (25 bytes)
 total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
 main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
 stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
 mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
 relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
 metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
 immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
 dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
 scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
 scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
 speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
--------------------------------------------------------------------------------
  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
--------------------------------------------------------------------------------
R20=0x0000f7cf1484ca18 is pointing into the stack for thread: 0x0000f7cf100305c0
R21=0x0000f7cf1484ca98 is pointing into the stack for thread: 0x0000f7cf100305c0
R22=0x0000f7cf1484d380 is pointing into the stack for thread: 0x0000f7cf100305c0
R23=0x0000f7cf1484d370 is pointing into the stack for thread: 0x0000f7cf100305c0
R24=0x0000f7cf1484d470 is pointing into the stack for thread: 0x0000f7cf100305c0
R25=0x000000000000000a is an unknown value
R26=0x000000ff0052b2b8 is pointing into metadata
R27=0x0 is null
R28=0x0000f7cf100305c0 is a thread
R29=0x0000f7cf1484c9d0 is pointing into the stack for thread: 0x0000f7cf100305c0
R30=0x0000f7cf14e83058: <offset 0x0000000000553058> in /testee-vm/lib/server/libjvm.so at 0x0000f7cf14930000

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3406595840

From kevinw at openjdk.org  Wed Oct 15 14:06:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 14:06:23 GMT
Subject: RFR: 8369894: Remove
 javax/management/remote/mandatory/loading/RMIDownloadTest.java from
 problemlist
In-Reply-To: <ixCU9PB2OY0UTJGVDTg2j0nu7HhSswgpbIsc_fm6PHI=.bde89f58-3f07-40b5-8a5b-95af365d70b8@github.com>
References: <NqEEtu6PWJUORs5P5Q5SVouAREdnqLVBHFKcAwBtxGk=.c43c7862-23d5-4592-8ff9-751af8b65322@github.com>
 <ixCU9PB2OY0UTJGVDTg2j0nu7HhSswgpbIsc_fm6PHI=.bde89f58-3f07-40b5-8a5b-95af365d70b8@github.com>
Message-ID: <1S3JF4llkMXITE11wjA9t1iCv5f-jy5eblnk0-ZXqsc=.e0084e3f-ce3d-45fb-8a9c-b1ab322327ca@github.com>

On Wed, 15 Oct 2025 13:56:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This was likely JDK-8282726 so removing it from the exclude list is okay. I assume you've run it many times to make sure it is stable.

Thanks, yes, big batch of tests with virtual threads, no problems.  I think JDK-8282726  fixes many things! 8-)   (I have at least one other to re-test and remove from the problemlist.)

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

PR Comment: https://git.openjdk.org/jdk/pull/27820#issuecomment-3406609118

From kevinw at openjdk.org  Wed Oct 15 14:10:27 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 14:10:27 GMT
Subject: Integrated: 8369894: Remove
 javax/management/remote/mandatory/loading/RMIDownloadTest.java from
 problemlist
In-Reply-To: <NqEEtu6PWJUORs5P5Q5SVouAREdnqLVBHFKcAwBtxGk=.c43c7862-23d5-4592-8ff9-751af8b65322@github.com>
References: <NqEEtu6PWJUORs5P5Q5SVouAREdnqLVBHFKcAwBtxGk=.c43c7862-23d5-4592-8ff9-751af8b65322@github.com>
Message-ID: <3Pj_vOaHSEe0oZmGtf2Nmnjl3r2AIuwklunlBC0nTE0=.a1c61071-b888-44ea-bc5e-dfc8107b0bb9@github.com>

On Wed, 15 Oct 2025 09:32:44 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted, like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now. Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

This pull request has now been integrated.

Changeset: 5191d720
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5191d72092a51d158ded061aa2e0f8a8231a9453
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8369894: Remove javax/management/remote/mandatory/loading/RMIDownloadTest.java from problemlist

Reviewed-by: alanb

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

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

From syan at openjdk.org  Wed Oct 15 14:28:21 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Oct 2025 14:28:21 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount
In-Reply-To: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
References: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
Message-ID: <PscS9GDkVMygSZ_3Eqg-2npWtGK99H9BJMkQxbj1Q7Y=.3ec1f0b3-2995-4ae9-ad32-ab503b60d693@github.com>

On Wed, 15 Oct 2025 14:18:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.
> 
> Change has been verified locally on linux-x64. Test fix only, no risk.
> 
> 
>> free -h
> total used free shared buff/cache available
> Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
> Swap: 0B 0B 0B
> 
> 
> Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
> OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)
> 
> 
> With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
> 137

@jerboaa @DamonFool Can you review this test bug fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27823#issuecomment-3406685435

From syan at openjdk.org  Wed Oct 15 14:28:20 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Oct 2025 14:28:20 GMT
Subject: RFR: 8343340: Swapping checking do not work for MetricsMemoryTester
 failcount
Message-ID: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>

Hi all,

The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.

Change has been verified locally on linux-x64. Test fix only, no risk.


> free -h
total used free shared buff/cache available
Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
Swap: 0B 0B 0B


Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:

> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
openjdk version "26" 2026-03-17
OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)


With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):

> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
137

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

Commit messages:
 - Fix import bug
 - 8343340: Swapping checking do not work for MetricsMemoryTester failcount

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

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

From eastigeevich at openjdk.org  Wed Oct 15 15:54:23 2025
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Wed, 15 Oct 2025 15:54:23 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <-Lv9OC8lY8jwMPZ0HxA1DUWoa611YLmOKM7JQmv0mpc=.607ec490-a9af-45b2-9a23-aa64a82d40c0@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <-Lv9OC8lY8jwMPZ0HxA1DUWoa611YLmOKM7JQmv0mpc=.607ec490-a9af-45b2-9a23-aa64a82d40c0@github.com>
Message-ID: <7HB--HqIsxx7wOEO95W-my4e462F4f99jqxZp2GxQA0=.f1ff5a91-5d69-4b40-9981-9588b264e9bf@github.com>

On Tue, 14 Oct 2025 23:44:39 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
>> 
>> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
>> 
>> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
>> 
>> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
>> 
>> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC
>
> The following occurs when running DeoptimizeRelocatedNMethod on PPC64
> 
> #  Internal Error (jdk/src/hotspot/cpu/ppc/nativeInst_ppc.cpp:405)
> #  assert(!decode(i1, i2)) failed: already patched
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x1701784]  NativePostCallNop::patch(int, int)+0xf4  (nativeInst_ppc.cpp:405)
> V  [libjvm.so+0x1718414]  nmethod::finalize_relocations()+0x6f4  (nmethod.cpp:2059)
> V  [libjvm.so+0x171891c]  nmethod::post_init()+0x5c  (nmethod.cpp:1252)
> V  [libjvm.so+0x171a8dc]  nmethod::relocate(CodeBlobType)+0x1ec  (nmethod.cpp:1515)
> V  [libjvm.so+0x200b598]  WB_RelocateNMethodFromMethod+0x388  (whitebox.cpp:1653)
> j  jdk.test.whitebox.WhiteBox.relocateNMethodFromMethod0(Ljava/lang/reflect/Executable;I)V+0
> j  jdk.test.whitebox.WhiteBox.relocateNMethodFromMethod(Ljava/lang/reflect/Executable;I)V+8
> j  compiler.whitebox.DeoptimizeRelocatedNMethod.main([Ljava/lang/String;)V+50
> 
> 
> @TheRealMDoerr @reinrich Do you have any ideas on a solution for this? I don't have any experience working with PPC so guidance would be greatly appreciated

@chadrako 
> StressNMethodRelocation.java runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. 

Maybe instead of hardcoding the number of methods (1024), we can have a reasonable time slice, e.g. 10 seconds, and compile as many methods as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3407142928

From kevinw at openjdk.org  Wed Oct 15 16:17:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 16:17:04 GMT
Subject: RFR: 8369924: Remove
 test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from
 problemlist
Message-ID: <XI76AQw-tLWmfzos1TpPPASZuq1FudzKxZb41dBjRAY=.a2b5dac8-582e-4973-b146-24a77967bf6e@github.com>

This test was probemlisted, like several tests that were occasionally hanging on Windows when used with virtual threads.

This test looks reliable now. Key change may have been [JDK-8282726](https://bugs.openjdk.org/browse/JDK-8282726).

Remove from problem list.

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

Commit messages:
 - Remove test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from problemlist

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

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

From duke at openjdk.org  Wed Oct 15 16:38:04 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Oct 2025 16:38:04 GMT
Subject: RFR: 8020207: jconsole fails connecting over SSL using
 service:jmx:rmi://...jndi...
In-Reply-To: <zrRemP36pH7JxZPw7tk117ugwJ20KQPFDkOGjBoYTIE=.0be695f2-9190-4816-b276-59ddc3ec3bb6@github.com>
References: <zrRemP36pH7JxZPw7tk117ugwJ20KQPFDkOGjBoYTIE=.0be695f2-9190-4816-b276-59ddc3ec3bb6@github.com>
Message-ID: <iYuttNjwtjDzMRE9nXpJNmvHtP3L93T5PZ4oVPkmCH4=.6f176cce-7f4d-407d-bb2b-4dcc8af26c05@github.com>

On Fri, 3 Oct 2025 12:00:13 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> This is the fix for the https://bugs.openjdk.org/browse/JDK-8020207, JConsole fails connecting over SSL using a string with a JMXServiceURL.
> 
> The cause of the issue is a connection to the RMI registry. If the registry and agent use SSLSockets and JConsole is trying to connect to the agent using "service:jmx:rmi..." URL, ProxyClient of the JConsole does not attempt to use SSL for communication with the registry, it always tries to connect using not secured Socket.
> 
> I would suggest to parse the JMXServiceURL and check the SSL config for the RMI registry for one specific case:
> 
> -  the schema of the JMXServiceURL is "rmi"
> -  the path of the JMXServiceURL is "/jndi/"
> -  the schema of the RMI registry URI is "rmi"
> -  the path of the RMI registry URI is "/jmxrmi".

@GennadiyKrivoshein 
Your change (at version 3d84f4667679fba2f52cd5d3594569a19b8f4eb6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27622#issuecomment-3407351054

From liach at openjdk.org  Wed Oct 15 17:03:33 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 17:03:33 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v7]
In-Reply-To: <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <i3xXD42MyZ_sNPNmbH1CSyOrj5w3RQg0QBuwAUuToQ8=.28cde42f-7311-426c-a410-cf38e938cca7@github.com>
 <Y_UY3lIZLD1cVvcOb5oJUJ55xe_2Pvacv_P4Dou329w=.b1cc92a7-661c-4468-8171-91fbc0a8695b@github.com>
Message-ID: <nBDHHCtDRuRHT8KW2ET2wynEcjRupIFKDOr1j9zAUdI=.efe054f1-b3b1-4269-a008-89040304508b@github.com>

On Wed, 15 Oct 2025 06:01:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chen Liang 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 16 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Ioi review
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - Merge branch 'fix/asm-test-upgrade' of github.com:liachmodded/jdk into fix/asm-test-upgrade
>>  - Update test/hotspot/jtreg/compiler/calls/common/InvokeDynamicPatcher.java
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Variable name improvements
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/asm-test-upgrade
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/63a83778...25972f2d
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:
> 
>> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
>> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
>> 94:                         // Remove dummy field
> 
> Q: Is this dummy field removed or added? Seems to be a mismatch between the comment and the real action.

Updated to indicate this shuffle is done to shuffle constant pools.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2433349624

From liach at openjdk.org  Wed Oct 15 17:03:26 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 17:03:26 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v8]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Serguei reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/25972f2d..e31476b1

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

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

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

From kvn at openjdk.org  Wed Oct 15 17:17:34 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 15 Oct 2025 17:17:34 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
Message-ID: <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>

On Mon, 6 Oct 2025 20:13:46 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
> 
> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
> 
> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
> 
> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
> 
> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC

Comments.

test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java line 30:

> 28:  * @library /test/lib /
> 29:  * @modules java.base/jdk.internal.misc java.management
> 30:  * @requires vm.opt.DeoptimizeALot != true & vm.gc.Serial

Suggestion:

@requires vm.gc == "null" | vm.gc == "Serial"

test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java line 42:

> 40:  * @library /test/lib /
> 41:  * @modules java.base/jdk.internal.misc java.management
> 42:  * @requires vm.opt.DeoptimizeALot != true & vm.gc.Parallel

@requires vm.gc == "null" | vm.gc == "Parallel"

test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java line 54:

> 52:  * @library /test/lib /
> 53:  * @modules java.base/jdk.internal.misc java.management
> 54:  * @requires vm.opt.DeoptimizeALot != true & vm.gc.G1

@requires vm.gc == "null" | vm.gc == "G1"

test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java line 66:

> 64:  * @library /test/lib /
> 65:  * @modules java.base/jdk.internal.misc java.management
> 66:  * @requires vm.opt.DeoptimizeALot != true & vm.gc.Shenandoah

@requires vm.gc == "null" | vm.gc == "Shenandoah"

test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java line 78:

> 76:  * @library /test/lib /
> 77:  * @modules java.base/jdk.internal.misc java.management
> 78:  * @requires vm.opt.DeoptimizeALot != true & vm.gc.Z

@requires vm.gc == "null" | vm.gc == "Z"

test/hotspot/jtreg/compiler/whitebox/RelocateNMethod.java line 32:

> 30:  * @modules java.base/jdk.internal.misc java.management
> 31:  *
> 32:  * @requires vm.opt.DeoptimizeALot != true & vm.gc.Serial

Same here as in test/hotspot/jtreg/compiler/whitebox/DeoptimizeRelocatedNMethod.java

test/hotspot/jtreg/compiler/whitebox/StressNMethodRelocation.java line 34:

> 32:  * @build jdk.test.whitebox.WhiteBox
> 33:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 34:  * @run main/othervm/timeout=600 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI

I prefer @eastig suggestion to limit run time instead of increase timeout.

test/hotspot/jtreg/compiler/whitebox/StressNMethodRelocation.java line 35:

> 33:  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
> 34:  * @run main/othervm/timeout=600 -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI
> 35:  *                   -XX:+SegmentedCodeCache -XX:+TieredCompilation -XX:+UnlockExperimentalVMOptions

I am not sure you need to specify `-XX:+SegmentedCodeCache -XX:+TieredCompilation `  because you require them to be enabled to run test.  Please, test that.

test/hotspot/jtreg/serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java line 29:

> 27:  * @bug 8316694
> 28:  * @summary Verify that nmethod relocation posts the correct JVMTI events
> 29:  * @requires vm.jvmti & vm.gc.Serial

* @requires vm.gc == "null" | vm.gc == "Serial"

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

PR Review: https://git.openjdk.org/jdk/pull/27659#pullrequestreview-3341481186
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433367608
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433368572
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433369949
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433371850
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433373000
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433374245
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433383437
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433386087
PR Review Comment: https://git.openjdk.org/jdk/pull/27659#discussion_r2433376516

From jsjolen at openjdk.org  Wed Oct 15 17:32:05 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Oct 2025 17:32:05 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
Message-ID: <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>

On Wed, 8 Oct 2025 22:11:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix copyright
>
> src/hotspot/share/oops/constantPool.cpp line 1626:
> 
>> 1624: void ConstantPool::copy_bsm_entries(const constantPoolHandle& from_cp,
>> 1625:                                  const constantPoolHandle& to_cp,
>> 1626:                                  TRAPS) {
> 
> Nit: Indent is not right.

These indentations faults have been all over (all my fault of course), thank you for spotting them.

> src/hotspot/share/oops/constantPool.inline.hpp line 90:
> 
>> 88:   return resolved_references()->obj_at(cache()->resolved_method_entry_at(index)->resolved_references_index());
>> 89: }
>> 90: 
> 
> Nit: Is this really needed?

I believe that the style is to have an empty line between the code and the endif, so this is a style fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2433423167
PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2433420483

From sspitsyn at openjdk.org  Wed Oct 15 17:39:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 17:39:10 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
 <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>
Message-ID: <uFftF0Pp22qeGU9xVXts6dmmzcblgUfgn23QfmEHIDM=.43d6147f-b26b-4873-bafe-55cc855e18dd@github.com>

On Wed, 15 Oct 2025 09:28:40 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?

It is because minimal does not include JVMTI.
A tweak is needed in `jvmtiExport.hpp` at line 383 as for all other functions returning `void`:
  `NOT_JVMTI_RETURN_(false)` => `NOT_JVMTI_RETURN`

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

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3407564232

From jsjolen at openjdk.org  Wed Oct 15 17:41:49 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Oct 2025 17:41:49 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v13]
In-Reply-To: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
Message-ID: <tfCV4U5zP2PfKhHYECcwSnZvhoSqzvjKMBhAS7Q_s9k=.30587383-a834-4c87-a0d7-5fcb710df4c4@github.com>

> Hi,
> 
> This is a refactoring of the way that we store the Bootstrap method attribute in the ConstantPool class. We used to have a single `Array<u2>` which was divided into a section of `u4` offsets and a section which was the actual data. In this refactoring we make this split more clear, by actually allocating an `Array<u4>` to store the offsets in and an `Array<u2>` to store the data in. These arrays are then put into a `BSMAttributeEntries` class, which allows us to separate out the API from that of the rest of the `ConstantPool`.
> 
> We had multiple instances of the code knowing the layout of the operands array and using this to do 'clever' ways of copying and inserting data into it. See `ConstantPool::copy_operands` and `ConstantPool::resize_operands`. I felt like we could do things in a simpler way, so I added the `start_/end_extension` protocol and added the `InsertionIterator` for this. See `ClassFileParser::parse_classfile_bootstrap_methods_attribute` for how this works. I put several relevant definitions into the inline file in hopes of encouraging the compiler to optimize these appropriately.
> 
> For the Java SA code, I had to add a `U4Array` class. I also had to fix the vmstructs definitions, etc.
> 
> On the whole, while this code is a bit less terse, I think it's a good API improvement and the underlying implementation of splitting up the operands array is also an improvement.
> 
> Testing: Oracle Tier1-Tier5 has been run succesfully multiple times. Before integration, I will merge with master and run these tiers again.

Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision:

  Some nits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27198/files
  - new: https://git.openjdk.org/jdk/pull/27198/files/bb3a014d..5e72da4e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27198&range=11-12

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

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

From jsjolen at openjdk.org  Wed Oct 15 17:41:51 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 15 Oct 2025 17:41:51 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v5]
In-Reply-To: <EvzHMyvWdTZrKA9JhZFZCuwQ-zR2zY6haj7iz2to2-k=.7666e0fb-94b0-45a9-9ddf-56d9bc8b8869@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <bAX8O0PP5H7vziejiwtWjXz43Xb5PIv3bdXVE-38pV0=.69eb362b-45ec-45cf-987d-788213878f3e@github.com>
 <9GaOIC1GMr4TNQ-P-K54NJF-vVqaAFAOFVNZNNOpWM4=.a2c29f92-b499-4780-8187-82693d512448@github.com>
 <4sDHlKErEtUHt0Y6uxCcqxnQX5Ztl8gNYsd8t_9pnmc=.7a7bf590-9e18-424c-9992-2d65d264c075@github.com>
 <EvzHMyvWdTZrKA9JhZFZCuwQ-zR2zY6haj7iz2to2-k=.7666e0fb-94b0-45a9-9ddf-56d9bc8b8869@github.com>
Message-ID: <GH9p2YVtLxbA4u7HL71A_nDn1fel0dIrhuXqoXV2Y6c=.700b1dfb-98ce-4a67-a824-f3c65e86b360@github.com>

On Wed, 8 Oct 2025 20:15:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>>>One query: have you done any performance measurements for this change? I'm a little concerned that the insertion iterator and the internal array management is now more heavyweight than the old array management.
>> 
>> I haven'e done any performance testing. I was considering doing so, but the majority of the work that has potentially been slowed down is when redefining classes via JVMTI, as this is when we got to do what essentially boiled down to a `memcpy`. My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?
>> 
>> Regardless, I'll have a look at doing some coarse-grained profiling via Aurora, and also have a look at the generated assembly. The goal of putting some of the functions in the inline file was to give enough context to the compiler so that it can do a good job of optimizing the code, we'll see if that was actually the case.
>
>> My understanding of JVMTI is that it's less performance sensitive than the usual JVM, as it's only used or tooling on a 'human' level (debuggers, etc). Is that understanding correct?
> 
> It depends. And no, it is not always 'human' level (debuggers, etc). It is used by profilers as well especially via Instrumentation API. And yes, JVMTI is that it's less performance sensitive than the usual JVM. However, it'd be nice to improve its performance, not degrade. :)

@sspitsyn , the points about detecting null are good. Let me look at those in more detail tomorrow. I need to a bit more fresh. You might be right, `guarantee` might be preferred here.

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

PR Comment: https://git.openjdk.org/jdk/pull/27198#issuecomment-3407569040

From cjplummer at openjdk.org  Wed Oct 15 17:48:32 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 Oct 2025 17:48:32 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11]
In-Reply-To: <ZvpsjEeOR_SbhXSPsP0boc7YImT_gokILJgISm4PocA=.f27f8b76-5dc8-4a44-82c4-6876dfe2299f@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ZvpsjEeOR_SbhXSPsP0boc7YImT_gokILJgISm4PocA=.f27f8b76-5dc8-4a44-82c4-6876dfe2299f@github.com>
Message-ID: <O1TVuvJ0Gs_tWaI76MKO2bUZ33upFMNrhGEAsLJ26bY=.e4190c81-a67b-48f4-b5af-206e85e4b76a@github.com>

On Wed, 15 Oct 2025 10:27:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cosmetic change

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3341612959

From sspitsyn at openjdk.org  Wed Oct 15 17:52:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 17:52:40 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v8]
In-Reply-To: <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>
Message-ID: <zVZ_EPdUZ0cdGJ6rQJQkTNH2oZQB3GujLfSon0yFe54=.f667c277-593f-49cf-bcb6-b074e7133645@github.com>

On Wed, 15 Oct 2025 17:03:26 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Serguei reviews

test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:

> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
> 94:                         // Defer dummy fields to defer their associated constant pool entries

Nit: This comment is kind of confusing. What does it mean: `defer dummy fields`? Do you mean `defer adding dummy fields to the class file`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2433474192

From sspitsyn at openjdk.org  Wed Oct 15 18:01:45 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 18:01:45 GMT
Subject: RFR: 8367656: Refactor Constantpool's operand array into two [v12]
In-Reply-To: <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>
References: <hD4IodTL57QsRYGfrQDmuO0iRsOGFClg92r_fSCD_-0=.ed750374-a87a-4463-986e-0d8635b4090b@github.com>
 <VoapD1FF3xOk4AMSdwval9xHLuOJqOkY5SQdjbQtJGc=.1a9ffbc4-bf3a-473e-8568-582a9a0270a5@github.com>
 <_0HzhdWbRBZNJvB33qf8VXRnc70eYXm7NCmb6oSEllw=.482f6b91-c612-4be7-a007-29954f0f5080@github.com>
 <KY3yO3STPuSOi1cY2yt7WtkMEn8SusspKXmYf6q0I2k=.2fc2a1c1-e2b3-416e-a8ee-9a0a1ccd5702@github.com>
Message-ID: <E5cp5rk8qtat-kiY3oBIQKp9CEk9jl43LBLn7PRg0OQ=.cd830d11-d7e0-4939-a63d-7787f9061e3e@github.com>

On Wed, 15 Oct 2025 17:28:02 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/oops/constantPool.inline.hpp line 90:
>> 
>>> 88:   return resolved_references()->obj_at(cache()->resolved_method_entry_at(index)->resolved_references_index());
>>> 89: }
>>> 90: 
>> 
>> Nit: Is this really needed?
>
> I believe that the style is to have an empty line between the code and the endif, so this is a style fix.

The issue is this is the only fix in this file. Should we go and fix all style issues around?
In fact, I'm okay with this tweak. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27198#discussion_r2433497456

From duke at openjdk.org  Wed Oct 15 18:03:43 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Wed, 15 Oct 2025 18:03:43 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
Message-ID: <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>

On Wed, 15 Oct 2025 17:14:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
>> 
>> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
>> 
>> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
>> 
>> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
>> 
>> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC
>
> Comments.

> @vnkozlov Could you provide your configure and more test output for https://bugs.openjdk.org/browse/JDK-8369150
> 
> I'm not able to reproduce

I'm not sure if you saw this because of the bot comments but I'm not able to reproduce the COH failure

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3407655874

From liach at openjdk.org  Wed Oct 15 18:21:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 18:21:50 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25124/files
  - new: https://git.openjdk.org/jdk/pull/25124/files/e31476b1..697b8555

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

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

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

From kvn at openjdk.org  Wed Oct 15 18:45:25 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 15 Oct 2025 18:45:25 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
Message-ID: <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>

On Wed, 15 Oct 2025 18:00:33 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> I'm not sure if you saw this because of the bot comments but I'm not able to reproduce the COH failure

@chadrako, I added test output to [8369150](https://bugs.openjdk.org/browse/JDK-8369150) bug report.

Do you unload old method after coping and let GC do it normal way?

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3407790926

From duke at openjdk.org  Wed Oct 15 19:20:39 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Wed, 15 Oct 2025 19:20:39 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
Message-ID: <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>

On Wed, 15 Oct 2025 18:42:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Do you unload old method after coping and let GC do it normal way?

When an nmethod is relocated the old is marked not entrant. Then yes it is unloaded normally by the GC. The issue is most likely the GC deciding not to unload it for whatever reason. I'll see if there is a more deterministic way to test this

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3407924235

From pchilanomate at openjdk.org  Wed Oct 15 20:02:14 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 15 Oct 2025 20:02:14 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11]
In-Reply-To: <ZvpsjEeOR_SbhXSPsP0boc7YImT_gokILJgISm4PocA=.f27f8b76-5dc8-4a44-82c4-6876dfe2299f@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ZvpsjEeOR_SbhXSPsP0boc7YImT_gokILJgISm4PocA=.f27f8b76-5dc8-4a44-82c4-6876dfe2299f@github.com>
Message-ID: <xCn7hb3vaUK55M4ugsoOEA_e_eeZwNqtszSfTPAjO_M=.1600f636-4b21-457b-b08d-d1f926156198@github.com>

On Wed, 15 Oct 2025 10:27:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cosmetic change

Looks good to me too, thanks for fixing this.

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

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27728#pullrequestreview-3342034292

From liach at openjdk.org  Wed Oct 15 20:33:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Oct 2025 20:33:54 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v8]
In-Reply-To: <zVZ_EPdUZ0cdGJ6rQJQkTNH2oZQB3GujLfSon0yFe54=.f667c277-593f-49cf-bcb6-b074e7133645@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <yr8_hMjBndhN28977YbuMQLuRr8MWnCHKPq6hCPu1cc=.1a9dd864-5dd8-4780-a2cd-b711db0ea1ec@github.com>
 <zVZ_EPdUZ0cdGJ6rQJQkTNH2oZQB3GujLfSon0yFe54=.f667c277-593f-49cf-bcb6-b074e7133645@github.com>
Message-ID: <Dh6PDPXaJp6JgE4_EqUZ74GZQkxySel5Pdz-P9C2-wc=.d338007e-cf64-40b1-bc43-5087c80eb5f4@github.com>

On Wed, 15 Oct 2025 17:49:11 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Serguei reviews
>
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineAnnotations.java line 94:
> 
>> 92:                 public void accept(ClassBuilder builder, ClassElement element) {
>> 93:                     if (element instanceof FieldModel field && field.fieldName().stringValue().startsWith("dummy")) {
>> 94:                         // Defer dummy fields to defer their associated constant pool entries
> 
> Nit: This comment is kind of confusing. What does it mean: `defer dummy fields`? Do you mean `defer adding dummy fields to the class file`?

I have updated this to indicate this is to hold on to the related constant pool entries and add them to the end instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25124#discussion_r2433861767

From lmesnik at openjdk.org  Wed Oct 15 20:44:29 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 Oct 2025 20:44:29 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
Message-ID: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>

Test might fail with 

----------System.out:(5/399)----------
The following fake exception stacktrace is for failure analysis.
nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
at nsk_lvcomplain(nsk_tools.cpp:172)
# ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
# jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE

if some of threads unexpectedly finishes during test execution. 


It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

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

Commit messages:
 - 8321687: Test vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java failed: JVMTI_ERROR_THREAD_NOT_ALIVE

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

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

From sspitsyn at openjdk.org  Wed Oct 15 21:49:20 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 21:49:20 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <HN_LsCjlBTXOdPYZvur9Z6G7EC6297Gey3et5KDqTN0=.f102b681-75cc-4f76-8c6e-c1b657329488@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

Thank you for the updates! I'm okay with the fix assuming it was verified with the mach5 tiers 1-6.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-3342461284

From cjplummer at openjdk.org  Wed Oct 15 22:08:32 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 15 Oct 2025 22:08:32 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <80ekEL9EFj0inZgRd44aF_gcIbBMxVPreVZ5Fo-V9lc=.ee7b8410-2e01-49d0-a873-cda6163dbcb9@github.com>

On Wed, 15 Oct 2025 20:38:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

Isn't this also an issue for tc03t001?

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp line 48:

> 46: static int numberOfDeadlocks = 0;
> 47: 
> 48: static const char* thread_name_prefix = "Debugee Thread";

I think "Debugee Thread" here and in the java source need a comment indicating that the C and java code need to be kept in sync. The java code should probably also assign it to a final field.

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

PR Review: https://git.openjdk.org/jdk/pull/27831#pullrequestreview-3342512588
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2434094541

From sspitsyn at openjdk.org  Wed Oct 15 22:14:41 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 15 Oct 2025 22:14:41 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <TBOyPkamep5_M_0QL19XuudvKiOYSkE8FOjeRDP7XrI=.75477baf-ad60-47b6-a2b2-296430d98b21@github.com>

On Wed, 15 Oct 2025 20:38:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp line 49:

> 47: 
> 48: static const char* thread_name_prefix = "Debugee Thread";
> 49: static size_t thread_name_prefix_len = strlen(thread_name_prefix);

Nit: I'd suggest to add a `const` specifier as it is a constant.
Also, both identifiers `thread_name_prefix` and `thread_name_prefix_len` is better to capitalize to reflect they are non-mutable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2434103741

From lmesnik at openjdk.org  Wed Oct 15 22:43:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 Oct 2025 22:43:41 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v2]
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <kEdXyipZwoNgeDLsAJYQNt_tqd-BETH2RkyS4vtsNwk=.78c9749d-bfde-4dce-9caf-f5d00e6de8ef@github.com>

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  updated after feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27831/files
  - new: https://git.openjdk.org/jdk/pull/27831/files/7cf8f9ff..385b3e00

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

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

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

From lmesnik at openjdk.org  Wed Oct 15 23:59:33 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 Oct 2025 23:59:33 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v3]
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <eauib7Sdd-zlE2d_Yvh1rwvd1T0Dyb6EQyfOmVyfPag=.b6a8accc-aa9f-44dc-879e-6b2aff8b210a@github.com>

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  added one more test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27831/files
  - new: https://git.openjdk.org/jdk/pull/27831/files/385b3e00..80fc4d55

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

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

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

From lmesnik at openjdk.org  Wed Oct 15 23:59:34 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 15 Oct 2025 23:59:34 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v3]
In-Reply-To: <80ekEL9EFj0inZgRd44aF_gcIbBMxVPreVZ5Fo-V9lc=.ee7b8410-2e01-49d0-a873-cda6163dbcb9@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <80ekEL9EFj0inZgRd44aF_gcIbBMxVPreVZ5Fo-V9lc=.ee7b8410-2e01-49d0-a873-cda6163dbcb9@github.com>
Message-ID: <l-rrHNknBcB607BF5-nE5m5dVvx1jqUrlqgkZljH8fI=.eb22bab7-c557-4696-8b0c-ae5627fb7d53@github.com>

On Wed, 15 Oct 2025 22:06:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Isn't this also an issue for tc03t001?

Thanks, I've updated this test also.

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

PR Comment: https://git.openjdk.org/jdk/pull/27831#issuecomment-3408668817

From sspitsyn at openjdk.org  Thu Oct 16 00:24:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 00:24:08 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v3]
In-Reply-To: <eauib7Sdd-zlE2d_Yvh1rwvd1T0Dyb6EQyfOmVyfPag=.b6a8accc-aa9f-44dc-879e-6b2aff8b210a@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <eauib7Sdd-zlE2d_Yvh1rwvd1T0Dyb6EQyfOmVyfPag=.b6a8accc-aa9f-44dc-879e-6b2aff8b210a@github.com>
Message-ID: <071AyBmWO7TifDr-aDIMfxjbFcsoFCwHFRN1eGR_-tU=.b1edce15-325f-4f9b-a7bb-0ed0666b2d75@github.com>

On Wed, 15 Oct 2025 23:59:33 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test might fail with 
>> 
>> ----------System.out:(5/399)----------
>> The following fake exception stacktrace is for failure analysis.
>> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> at nsk_lvcomplain(nsk_tools.cpp:172)
>> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
>> 
>> if some of threads unexpectedly finishes during test execution. 
>> 
>> 
>> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added one more test

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp line 109:

> 107:     int pThread, cThread;
> 108:     int i;
> 109:     int debuggee_thread_cnt = 0;

This does not follow the same pattern as in `[tc03t002.cpp](https://github.com/openjdk/jdk/pull/27831/files#diff-3299265c6356bba38c26589bc9d4fd1b32ad679ff0802c168e732490c8986a6d)`.
The variable `debuggee_thread_cnt` is not correctly set and used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2434259674

From lmesnik at openjdk.org  Thu Oct 16 00:41:37 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 00:41:37 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v4]
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <bfplPYwHju2PIwPn5ZOz7OozCeaa8cGnTK9s2fFYhkI=.9a73eb01-be1d-4990-a924-bcea8a08c563@github.com>

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

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

 - space added
 - fix
 - fixed applied

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27831/files
  - new: https://git.openjdk.org/jdk/pull/27831/files/80fc4d55..e70b8841

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

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

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

From lmesnik at openjdk.org  Thu Oct 16 00:41:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 00:41:39 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v3]
In-Reply-To: <071AyBmWO7TifDr-aDIMfxjbFcsoFCwHFRN1eGR_-tU=.b1edce15-325f-4f9b-a7bb-0ed0666b2d75@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <eauib7Sdd-zlE2d_Yvh1rwvd1T0Dyb6EQyfOmVyfPag=.b6a8accc-aa9f-44dc-879e-6b2aff8b210a@github.com>
 <071AyBmWO7TifDr-aDIMfxjbFcsoFCwHFRN1eGR_-tU=.b1edce15-325f-4f9b-a7bb-0ed0666b2d75@github.com>
Message-ID: <-mNRz42ZTyc16xPr057pFOOEEEmxKaxmy2yk9Ki_44E=.a405ebe9-6307-4709-aa35-04d816b7ef41@github.com>

On Thu, 16 Oct 2025 00:21:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added one more test
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp line 109:
> 
>> 107:     int pThread, cThread;
>> 108:     int i;
>> 109:     int debuggee_thread_cnt = 0;
> 
> This does not follow the same pattern as in `tc03t002.cpp`.
> The variable `debuggee_thread_cnt` is not correctly set and used.

Thanks! Corrected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2434277100

From lmesnik at openjdk.org  Thu Oct 16 02:09:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:09:46 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
Message-ID: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>

> The problemlist entries for incompatible tests are replaced with requires tag.
> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
> 
> Tested by running these tests with virtual test tthread factory.

Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:

 - copyrights updated
 - more tests removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27834/files
  - new: https://git.openjdk.org/jdk/pull/27834/files/2c882158..eafa8d21

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

  Stats: 11 lines in 5 files changed: 2 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/27834.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27834/head:pull/27834

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

From dholmes at openjdk.org  Thu Oct 16 02:29:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 02:29:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Seems reasonable.

Would be good to know why some tests have stopped failing though.

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3342855898

From lmesnik at openjdk.org  Thu Oct 16 02:43:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 02:43:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
Message-ID: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>

On Thu, 16 Oct 2025 02:26:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems reasonable.
> 
> Would be good to know why some tests have stopped failing though.
> 
> Thanks
Thank you for reveiw.
For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3408951683

From alanb at openjdk.org  Thu Oct 16 05:35:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 05:35:03 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
Message-ID: <kDmJ5o4QFqg8obNyDv-h2iRgOsEO1sOc0ylwJo8_pOQ=.ebc36fa0-13ca-40ab-8fd8-d80038bd9025@github.com>

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
>
>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
> Thank you for reveiw.
> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

@lmesnik - would I be correct to say that you are on a mission to get rid of ProblemList-Virtual completely? Just to mention that there are a number of tests that already skip when the test main thread is a virtual thread. We may need to track these down and replace them with `@requires test.thread.factory == null` so that it is cleared from the test description.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409239412

From alanb at openjdk.org  Thu Oct 16 05:39:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 05:39:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
Message-ID: <tTDpaMj7Jf8SLq4VToanf2gdX2jb6h8brmQxt6EqBPQ=.f4776444-7404-42d7-85a2-22936ee6ef88@github.com>

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

Right, virtual threads did not capture the caller context (inherited AccessControlContext) and had no permissions when executing code that performed a privileged action. This is why some of the pre-existing tests that ran with a security manager couldn't run with JTREG_TEST_THREAD_FACTORY=Virtual.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409247117

From lmesnik at openjdk.org  Thu Oct 16 05:57:01 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 05:57:01 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
Message-ID: <M10Ei_E-4ns4IxmB6tCPgJla79vGBz8rVjiwiakFiBs=.4cd08210-fdb9-4d62-9e77-e8d744435dd8@github.com>

On Thu, 16 Oct 2025 02:40:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
>
>> Seems reasonable.
>> 
>> Would be good to know why some tests have stopped failing though.
>> 
>> Thanks
> Thank you for reveiw.
> For most if not all cases the reason is Security Manager removal. The tests failed to obtain permissions from virtual threads.

> @lmesnik - would I be correct to say that you are on a mission to get rid of ProblemList-Virtual completely? Just to mention that there are a number of tests that already skip when the test main thread is a virtual thread. We may need to track these down and replace them with `@requires test.thread.factory == null` so that it is cleared from the test description.

I am going to mark with requires all incompatible tests. There are some tests that manually check if virtual thread is enabled and the tests that already have virtual thread cases. I'll clean up them later.

However, the ProblemList-Virtual  will remain. It should contains the test that fail because of bugs. Including RFE to improve test to support virtual threads.
 The
`@requires test.thread.factory == null` 
means that test is incompatible with thread factory and unlikely is going to be fixed for this mode.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409283143

From alanb at openjdk.org  Thu Oct 16 06:06:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 06:06:07 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <B5m3Q1-vChX60xoKrHh0wpiSRZ1CA6ojSpsPtUFfs1E=.9d20fe9e-1479-4b24-94a1-e3d331116dd9@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3343180403

From alanb at openjdk.org  Thu Oct 16 06:06:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 16 Oct 2025 06:06:08 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <M10Ei_E-4ns4IxmB6tCPgJla79vGBz8rVjiwiakFiBs=.4cd08210-fdb9-4d62-9e77-e8d744435dd8@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <N_ASLogrvlUNW675ooHVbECd5eboccn-NX79etbroBY=.fc0352c3-f768-43a8-a582-491f878f9eb3@github.com>
 <MTsduElb3VAkZ3xbHDfyceH0k9D8xsrEPRa-js56Mh8=.9b7c6f63-27c2-4756-b430-4ea63247171c@github.com>
 <M10Ei_E-4ns4IxmB6tCPgJla79vGBz8rVjiwiakFiBs=.4cd08210-fdb9-4d62-9e77-e8d744435dd8@github.com>
Message-ID: <7DwLsAuTCiYYr6lPN9vlLT8SzjWMRoHphbFDuLQjenU=.8296b6bd-8460-440c-a4c8-daf3dfd49325@github.com>

On Thu, 16 Oct 2025 05:54:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> However, the ProblemList-Virtual will remain. It should contains the test that fail because of bugs. Including RFE to improve test to support virtual threads.

Thanks for the clarification.

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

PR Comment: https://git.openjdk.org/jdk/pull/27834#issuecomment-3409309033

From syan at openjdk.org  Thu Oct 16 06:27:02 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 16 Oct 2025 06:27:02 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <wszw7ZYo4T6lwhiwAv4C9eh5Ls-5DCMVmb35M5QGA8E=.934bce79-35f7-4a58-9599-1aa3b5406b74@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3343230765

From dholmes at openjdk.org  Thu Oct 16 07:42:19 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 07:42:19 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
Message-ID: <tvm7WeykkWNGC8M4ssWhU77Zg0avhIxA1nJxLSt_6_Y=.3f1ff410-659b-4191-80bb-ba507578bba8@github.com>

On Wed, 15 Oct 2025 13:52:11 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore comment

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27777#pullrequestreview-3343463795

From fandreuzzi at openjdk.org  Thu Oct 16 08:15:32 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 08:15:32 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v2]
In-Reply-To: <uFftF0Pp22qeGU9xVXts6dmmzcblgUfgn23QfmEHIDM=.43d6147f-b26b-4873-bafe-55cc855e18dd@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <oJI3fZOgNpKj1XJ6OHkxgVA9CwmFFrXngH8BSr80pAY=.b579a38a-7233-44a2-a2c7-5b6c033f8ac1@github.com>
 <d-CdIzDq1yGo5VU1XPiHopkuyhBL6i-7bLQ6sdJHRyg=.815b133e-24f7-448d-8cff-3b9162565388@github.com>
 <uFftF0Pp22qeGU9xVXts6dmmzcblgUfgn23QfmEHIDM=.43d6147f-b26b-4873-bafe-55cc855e18dd@github.com>
Message-ID: <Jkvi_lJ3fKUn0-C7I29xXCKgbUR2w7nz-0GdYr2umsg=.642d5c9d-4a89-43e1-96f7-a6c5c4e14290@github.com>

On Wed, 15 Oct 2025 17:36:09 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?
>
>> Anybody knows why [this failure](https://github.com/fandreuz/jdk/actions/runs/18523317228/job/52788441879#step:9:3189) happened only in linux-x64-hs-minimal? Shouldn't it fail everywhere?
> 
> It is because minimal does not include JVMTI.
> A tweak is needed in `jvmtiExport.hpp` at line 383 to follow other functions returning `void`:
>   `NOT_JVMTI_RETURN_(false)` => `NOT_JVMTI_RETURN`

Thanks for the review @sspitsyn and @dholmes-ora.

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

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3409720063

From duke at openjdk.org  Thu Oct 16 08:15:35 2025
From: duke at openjdk.org (duke)
Date: Thu, 16 Oct 2025 08:15:35 GMT
Subject: RFR: 8369734: JvmtiExport::post_class_file_load_hook return value
 is never used [v4]
In-Reply-To: <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
 <MQyN7DZpqGIs7Zj9jLCK4CdVmXbhQXGJZAzSHFvHaqQ=.8fb509ac-a194-4412-b05d-5f686fa59fc8@github.com>
Message-ID: <mT2NHodFLytJj4gXKu01DauHf2HUQa84uRUd7OI9rrU=.95de2f86-fb65-4d19-b787-6114413b99fe@github.com>

On Wed, 15 Oct 2025 13:52:11 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   restore comment

@fandreuz 
Your change (at version 378174203615473d5216cc67fbde50933c3c1c87) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27777#issuecomment-3409722637

From dholmes at openjdk.org  Thu Oct 16 08:32:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 16 Oct 2025 08:32:17 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
Message-ID: <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>

On Tue, 14 Oct 2025 08:17:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   summary

Generally looks good. Not 100% sure on the test structure but serviceability folk can chime in there if needed.

Suggestion:

diff --git a/src/jdk.jcmd/share/man/jcmd.md b/src/jdk.jcmd/share/man/jcmd.md
index 4e67e7a4502..69784050984 100644
--- a/src/jdk.jcmd/share/man/jcmd.md
+++ b/src/jdk.jcmd/share/man/jcmd.md
@@ -551,7 +551,7 @@ ## Commands for jcmd
     events, use `JFR.view all-events`.
 
 `JVMTI.agent_load` [*arguments*]
-:   Loads JVMTI native agent.
+:   Loads JVMTI native agent. (Live phase only)
 
     Impact: Low

src/hotspot/share/prims/jvmtiAgentList.cpp line 200:

> 198:                                 const char* options, outputStream* st) {
> 199:   if (JvmtiEnvBase::get_phase() != JVMTI_PHASE_LIVE) {
> 200:     st->print_cr("Not in live phase");

Suggestion:

    st->print_cr("Dynamic agent loading is only permitted in the live phase");

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 45:

> 43:                 "-agentpath:" + Utils.TEST_NATIVE_PATH + File.separator + System.mapLibraryName("EarlyDynamicLoad"),
> 44:                 "-version");
> 45:         pb.environment().put("MODE", "jcmd");

This env-var seems unused

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 50:

> 48: 
> 49:         OutputAnalyzer output = new OutputAnalyzer(pb.start());
> 50:         output.shouldHaveExitValue(0);

Yes but more importantly we should be checking for the "not in live phase" error message.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3343557488
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2434967688
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2435031512
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2435035321

From ayang at openjdk.org  Thu Oct 16 09:35:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Oct 2025 09:35:34 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded
Message-ID: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>

Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.

The failure rate is ~60% before the fix and no failure for 2000 runs.

Test: tier1-5

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

Commit messages:
 - test-unload

Changes: https://git.openjdk.org/jdk/pull/27840/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342659
  Stats: 42 lines in 2 files changed: 8 ins; 27 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27840/head:pull/27840

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

From krk at openjdk.org  Thu Oct 16 10:13:20 2025
From: krk at openjdk.org (Kerem Kat)
Date: Thu, 16 Oct 2025 10:13:20 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal
Message-ID: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>

Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.

- Removed x86-specific implementations and ifdef blocks.
- Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
- Cleaned up platform detection logic in `PlatformInfo`.
- Updated documentation references.

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

Commit messages:
 - Clean up Hotspot SA after 32-bit x86 removal

Changes: https://git.openjdk.org/jdk/pull/27844/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27844&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351194
  Stats: 2747 lines in 45 files changed: 607 ins; 2094 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/27844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27844/head:pull/27844

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

From fandreuzzi at openjdk.org  Thu Oct 16 10:30:32 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 10:30:32 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v3]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <gVvybIYNjKA6Bb_l8muhJWff7rTiupvMsLWj1bZM4vg=.bb3a8951-820b-4a1a-983e-e9e808d053a4@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/prims/jvmtiAgentList.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/49722e1b..84f168b6

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

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

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

From fandreuzzi at openjdk.org  Thu Oct 16 11:12:37 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:12:37 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v4]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <W_GY_grNidBN10kxjNEMKVpMy3LFnZwcAd5safYp7vc=.2696e7d5-7a8c-4b29-b9fe-cd95aea6af3f@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  nn

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/84f168b6..2e21bc3f

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

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

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

From fandreuzzi at openjdk.org  Thu Oct 16 11:12:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:12:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
Message-ID: <V_N8NCUbRDEZ6KlbYAP4JMLgs5KJzTe8h6ozx-4zewo=.c30fd640-821b-42b8-8b72-7bddc6511bd2@github.com>

On Thu, 16 Oct 2025 08:26:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 45:
> 
>> 43:                 "-agentpath:" + Utils.TEST_NATIVE_PATH + File.separator + System.mapLibraryName("EarlyDynamicLoad"),
>> 44:                 "-version");
>> 45:         pb.environment().put("MODE", "jcmd");
> 
> This env-var seems unused

Thanks, that's a leftover from an old iteration: 2e21bc3f38404183bb0677980732ba1487d110d0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2435496765

From fandreuzzi at openjdk.org  Thu Oct 16 11:46:48 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:46:48 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v5]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <w5wf_ekwaYyrPzDpU3SkytOPiy_h2Po1EpKukd0HI8o=.b56bc090-430d-44cb-a200-2b0c20cc7660@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  errno

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/2e21bc3f..e9646e68

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

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

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

From fandreuzzi at openjdk.org  Thu Oct 16 11:57:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:57:47 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v6]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <ihMM18M_Zrx28lg9GT4ioqDArXAswLLuUcH5wP6vpck=.967549aa-5665-4d15-8a9a-e8115479049e@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  ops

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/e9646e68..cbbbf8a2

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

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

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

From ayang at openjdk.org  Thu Oct 16 12:12:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Oct 2025 12:12:34 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <Ng7I3shTt1Zp_AUVPirNxnUmR-fsqVlKg_SLLVM-sDI=.e89003c5-f299-4830-a17b-23421ab11e8e@github.com>

On Thu, 16 Oct 2025 10:05:08 GMT, Kerem Kat <krk at openjdk.org> wrote:

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27844#pullrequestreview-3344499070

From ysuenaga at openjdk.org  Thu Oct 16 12:48:37 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 16 Oct 2025 12:48:37 GMT
Subject: RFR: 8369505: jhsdb jstack cannot handle continuation stub [v11]
In-Reply-To: <ZvpsjEeOR_SbhXSPsP0boc7YImT_gokILJgISm4PocA=.f27f8b76-5dc8-4a44-82c4-6876dfe2299f@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
 <ZvpsjEeOR_SbhXSPsP0boc7YImT_gokILJgISm4PocA=.f27f8b76-5dc8-4a44-82c4-6876dfe2299f@github.com>
Message-ID: <DBQ_WYTOoYLRnQzaQcpiFLjTp2VJlB19sBG2SChxYsA=.29b0b3ee-df82-43c8-ad4f-f0177f3c998a@github.com>

On Wed, 15 Oct 2025 10:27:24 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
>> 
>> 
>> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
>> 
>> 
>> And also I got following (strange) stacks which causes `AssersionFailure` in above:
>> 
>> 
>> ----------------- 70094 -----------------
>> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
>> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
>> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
>> 0x00007f8f646bb14e __sleep + 0x3e
>> 0x00007f8f4b3a8e1e <nep_invoker_blob>
>> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cosmetic change

Thanks everyone for involving this PR!

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

PR Comment: https://git.openjdk.org/jdk/pull/27728#issuecomment-3410726254

From ysuenaga at openjdk.org  Thu Oct 16 12:48:39 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 16 Oct 2025 12:48:39 GMT
Subject: Integrated: 8369505: jhsdb jstack cannot handle continuation stub
In-Reply-To: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
References: <3uXrvSl-Ieuw2uP3b33cTKexGt3hWAZfKjtakG5VOy4=.5f9cd97a-191e-412e-be4d-fe6da1c2cdb8@github.com>
Message-ID: <DeqrkJjQBufmmFidivyoVJxSD0kBGI1bdRIUQZV0MNw=.6f116d0e-c6dd-4f3b-9c2e-4852803996ce@github.com>

On Thu, 9 Oct 2025 14:11:39 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get mixed thread dump of the application which runs virtual threads (see [Test.java on JBS](https://bugs.openjdk.org/secure/attachment/116453/Test.java)) via `jhsdb jstack --mixed`, then I got following message:
> 
> 
> sun.jvm.hotspot.utilities.AssertionFailure: must have non-zero frame size
>         at jdk.hotspot.agent/sun.jvm.hotspot.utilities.Assert.that(Assert.java:32)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.senderForCompiledFrame(X86Frame.java:374)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.x86.X86Frame.sender(X86Frame.java:273)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.sender(Frame.java:225)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Frame.realSender(Frame.java:230)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.sender(VFrame.java:120)
>         at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VFrame.javaSender(VFrame.java:150)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.initJFrameCache(PStack.java:224)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:73)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:65)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.PStack.run(PStack.java:60)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.run(JStack.java:67)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
>         at jdk.hotspot.agent/sun.jvm.hotspot.tools.JStack.runWithArgs(JStack.java:90)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJSTACK(SALauncher.java:306)
>         at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
> 
> 
> And also I got following (strange) stacks which causes `AssersionFailure` in above:
> 
> 
> ----------------- 70094 -----------------
> "ForkJoinPool-1-worker-4" #32 daemon prio=5 tid=0x00007f8f5c371660 nid=70094 runnable [0x00007f8f406d9000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007f8f64658462 __syscall_cancel_arch + 0x32
> 0x00007f8f6464c75c __internal_syscall_cancel + 0x5c
> 0x00007f8f646a8c37 __GI___nanosleep + 0x17
> 0x00007f8f646bb14e __sleep + 0x3e
> 0x00007f8f4b3a8e1e <nep_invoker_blob>
> 0x00007f8f4b33fe48 * java.lang.invoke.LambdaForm$MH+0x000000000c047000.invoke(java.lang.Object, long, int) bci:10 (Interpreted frame)
> 0x00007f8f4b33fe48...

This pull request has now been integrated.

Changeset: 16539998
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1653999871c8d7b1e61b44f8525e09b2cd0bdb6b
Stats:     297 lines in 10 files changed: 293 ins; 0 del; 4 mod

8369505: jhsdb jstack cannot handle continuation stub

Reviewed-by: cjplummer, pchilanomate

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

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

From krk at openjdk.org  Thu Oct 16 13:58:09 2025
From: krk at openjdk.org (Kerem Kat)
Date: Thu, 16 Oct 2025 13:58:09 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - Clean up Hotspot SA after 32-bit x86 removal

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

Changes: https://git.openjdk.org/jdk/pull/27844/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27844&range=01
  Stats: 2779 lines in 45 files changed: 623 ins; 2110 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/27844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27844/head:pull/27844

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

From fandreuzzi at openjdk.org  Thu Oct 16 14:09:14 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 14:09:14 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v7]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <2HmDhZbnCD5D_yBN1_xm0MC9nPvqlYYnRD9QazfJCjE=.d59989aa-1258-4390-8c09-6c2ae4ad7be5@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  debug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/cbbbf8a2..b53c2da4

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

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

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

From ysuenaga at openjdk.org  Thu Oct 16 14:45:15 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 16 Oct 2025 14:45:15 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with cold
 attribute
Message-ID: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>

`jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.


----------------- 120485 -----------------
"Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   JavaThread state: _thread_blocked
0x00007f50e4710735 __GI_abort + 0x8b
0x00007f50e1e01f33 ????????


0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:


(gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
   0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
=> 0x00007f50e1e01f33: nop
End of assembler dump.


libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.

After this PR, you can see the right symbol as following:


----------------- 120485 -----------------
"Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   JavaThread state: _thread_blocked
0x00007f50e4710735      __GI_abort + 0x8b
0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

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

Commit messages:
 - 8369994: Mixed mode jhsdb jstack cannot resolve symbol with cold attribute

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

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

From lmesnik at openjdk.org  Thu Oct 16 14:46:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 14:46:15 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v7]
In-Reply-To: <2HmDhZbnCD5D_yBN1_xm0MC9nPvqlYYnRD9QazfJCjE=.d59989aa-1258-4390-8c09-6c2ae4ad7be5@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <2HmDhZbnCD5D_yBN1_xm0MC9nPvqlYYnRD9QazfJCjE=.d59989aa-1258-4390-8c09-6c2ae4ad7be5@github.com>
Message-ID: <dqOdtBWdsJOzy51dX77W_1tB1knaWLLEckQ1kWisCDA=.f2fd42b5-bec6-419f-a757-4eb059ee64de@github.com>

On Thu, 16 Oct 2025 14:09:14 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   debug

Changes requested by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3337581027

From lmesnik at openjdk.org  Thu Oct 16 14:46:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 14:46:19 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
Message-ID: <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>

On Tue, 14 Oct 2025 08:17:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   summary

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadAttach.java line 40:

> 38: import jdk.test.lib.JDKToolFinder;
> 39: 
> 40: public class TestEarlyDynamicLoadAttach {

We don't usually have individual tests on the 'serviceability' level. 
Please move test into 'attach' folder. It is test for fix in the attach mechanism.

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 38:

> 36: static void JNICALL VMStartJcmd(jvmtiEnv* jvmti, JNIEnv* env) {
> 37:     char cmd[256];
> 38:     snprintf(cmd, sizeof(cmd), "%s %d JVMTI.agent_load some.jar", getenv("JCMD_PATH"), PID());

Wouldn't be easier to have single env variable like ATTACH_CMD `.../bin/jcmd 45678 JVMTI.agent_load some.jar` which is completely set by java? So native code is simplified and there are less dependencies.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2430534383
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2430539286

From sgehwolf at openjdk.org  Thu Oct 16 15:31:20 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 16 Oct 2025 15:31:20 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount
In-Reply-To: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
References: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
Message-ID: <f9vQI006FNcPw81wUBCyR5qDOQBmU8NHvQ7R3f2YZMI=.5eea614a-64a6-409a-8169-8c235857d913@github.com>

On Wed, 15 Oct 2025 14:18:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.
> 
> Change has been verified locally on linux-x64. Test fix only, no risk.
> 
> 
>> free -h
> total used free shared buff/cache available
> Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
> Swap: 0B 0B 0B
> 
> 
> Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
> OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)
> 
> 
> With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
> 137

Please amend the comment on line 114 to something like this:


        // Check whether swapping really works for this test
        // On some systems there is no swap space enabled. And running
        // 'java -Xms{mem-limit} -Xmx{mem-limit} -XX:+AlwaysPreTouch -version'
        // would fail due to swap space size being 0. Note that when swap is
        // properly enabled on the system the container gets the same amount
        // of swap as is configured for memory. Thus, 2x{mem-limit} is the actual
        // memory and swap bound for this pre-test.

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

PR Review: https://git.openjdk.org/jdk/pull/27823#pullrequestreview-3345562755

From kevinw at openjdk.org  Thu Oct 16 16:01:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 16 Oct 2025 16:01:29 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute
In-Reply-To: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
Message-ID: <LblFVc6fV6iVrY4LjKA2PMAa5oyYxpgfISPyAP7EgD4=.d305a4e0-74da-4de7-9383-eda325a2c1d4@github.com>

On Thu, 16 Oct 2025 13:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

Hi -
On the point about the range being too short, is it because the func is "cold", or is it only because the function ends in a call?
(for this example both are true 8-) )

I mean, do we see all .cold symbols as too short, even if they don't end in a call?  Or do they all end in a call so it's not simple to tell? (Maybe there aren't that many.)

This is only an issue if there is no gap between functions... But there might not always be a gap?

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

PR Review: https://git.openjdk.org/jdk/pull/27846#pullrequestreview-3345697061

From liach at openjdk.org  Thu Oct 16 16:00:03 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 Oct 2025 16:00:03 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <WdMoWavTzv3sZZpCyqhMcrhJyiDQ64MSn42eW4w8l4o=.cd1fe863-a91d-42fe-a4c5-29ef0111d9cc@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

Ran tier 1-6 and saw no related failure. Should I wait for another reviewer?

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

PR Comment: https://git.openjdk.org/jdk/pull/25124#issuecomment-3411569290

From cjplummer at openjdk.org  Thu Oct 16 16:43:16 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 16:43:16 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded
In-Reply-To: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
Message-ID: <wheMQo8VK-vFcSXG8lgjT6Pqln9h6VNw6OY8KfkVDf8=.01473d60-cbe0-4590-8aef-4f01464c0845@github.com>

On Thu, 16 Oct 2025 09:25:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
> 
> The failure rate is ~60% before the fix and no failure for 2000 runs.
> 
> Test: tier1-5

test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 250:

> 248: 
> 249:         // free references to class and class loader to be able for collecting by GC
> 250:         long waitTimeout = (customClassLoader == null) ? 0 : WAIT_TIMEOUT;

waitTimeout is no longer needed. You can also remove WAIT_TIMEOUT and WAIT_DELTA.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2436689604

From cjplummer at openjdk.org  Thu Oct 16 16:50:50 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 16:50:50 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded
In-Reply-To: <wheMQo8VK-vFcSXG8lgjT6Pqln9h6VNw6OY8KfkVDf8=.01473d60-cbe0-4590-8aef-4f01464c0845@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
 <wheMQo8VK-vFcSXG8lgjT6Pqln9h6VNw6OY8KfkVDf8=.01473d60-cbe0-4590-8aef-4f01464c0845@github.com>
Message-ID: <r-rpnHi3DJI7VKwXCY2NBsWztJ_dysY4jpXu4RGcR90=.95619a32-de67-4b14-adf0-0ed6bc9adce0@github.com>

On Thu, 16 Oct 2025 16:40:38 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
>> 
>> The failure rate is ~60% before the fix and no failure for 2000 runs.
>> 
>> Test: tier1-5
>
> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 250:
> 
>> 248: 
>> 249:         // free references to class and class loader to be able for collecting by GC
>> 250:         long waitTimeout = (customClassLoader == null) ? 0 : WAIT_TIMEOUT;
> 
> waitTimeout is no longer needed. You can also remove WAIT_TIMEOUT and WAIT_DELTA.

Sorry, looks like I misread the diff and waitTimeout was already removed. WAIT_TIMEOUT and WAIT_DELTA still need removing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2436707826

From cjplummer at openjdk.org  Thu Oct 16 16:56:56 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 16:56:56 GMT
Subject: RFR: 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is
 broken and should be removed [v2]
In-Reply-To: <Ap_l-vS9OOM98dJ-0uLeaiUlno5TMW7PHqdBFZTDQFo=.9dcaf940-b7fb-4ab2-87b0-07951a23573e@github.com>
References: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>
 <Ap_l-vS9OOM98dJ-0uLeaiUlno5TMW7PHqdBFZTDQFo=.9dcaf940-b7fb-4ab2-87b0-07951a23573e@github.com>
Message-ID: <tlKGuMIea-LXpMjTuq0fht5zhWGDGQa-F5h5Gd9z-Vc=.32a2a09d-c056-4837-94b8-9469cc18a1ae@github.com>

On Wed, 8 Oct 2025 22:47:24 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Remove support for the debug agents USE_ITERATE_THROUGH_HEAP support, and the debugflags option used to enable it. Support has been broken for a very long time and can't possibly be relied on by anyone. Please see the CR for a full description.
>> 
>> Note there is a very small compatibility risk with removing the debugflags option (any script that uses it would break). But since it was only used in support of USE_ITERATE_THROUGH_HEAP, is not included in the docs, and is only included in the help output for debug builds, I think the risk is very low. If used, script failures are likely a good thing as it would call attention to the fact that the user is attempting to use functionality that doesn't (and hasn't) worked.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of no longer needed cbObjectTagInstance() function

Thank you for the reviews Alex and Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/27706#issuecomment-3411771956

From cjplummer at openjdk.org  Thu Oct 16 16:56:57 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 16:56:57 GMT
Subject: Integrated: 8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP
 is broken and should be removed
In-Reply-To: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>
References: <_uvMqNDdvhwpH2zepMgDNVr3jCdF9PnIyoitvrOreOI=.aa1784e4-2a07-4d12-bbe7-6b324613c145@github.com>
Message-ID: <VsaFIPDtUIw6r_Mt0S8JSJ377yusr3ZzYS0VM1znHzg=.2a64d89b-b0d3-4247-a0e4-0d2b7735fe86@github.com>

On Wed, 8 Oct 2025 21:52:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Remove support for the debug agents USE_ITERATE_THROUGH_HEAP support, and the debugflags option used to enable it. Support has been broken for a very long time and can't possibly be relied on by anyone. Please see the CR for a full description.
> 
> Note there is a very small compatibility risk with removing the debugflags option (any script that uses it would break). But since it was only used in support of USE_ITERATE_THROUGH_HEAP, is not included in the docs, and is only included in the help output for debug builds, I think the risk is very low. If used, script failures are likely a good thing as it would call attention to the fact that the user is attempting to use functionality that doesn't (and hasn't) worked.

This pull request has now been integrated.

Changeset: 873666d1
Author:    Chris Plummer <cjplummer at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/873666d157340b3b953ad869576afd30d4304610
Stats:     101 lines in 3 files changed: 2 ins; 79 del; 20 mod

8369451: Debug agent support for USE_ITERATE_THROUGH_HEAP is broken and should be removed

Reviewed-by: sspitsyn, amenkov

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

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

From cjplummer at openjdk.org  Thu Oct 16 17:33:36 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 17:33:36 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]
In-Reply-To: <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
Message-ID: <z0iqU4MgsvUh_B4IsEWwArMkz7h9aKKZ5RVJDbKPLKQ=.7ddc6d45-7ed8-4d54-a3a2-dbe997911bd7@github.com>

On Thu, 16 Oct 2025 13:58:09 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - Clean up Hotspot SA after 32-bit x86 removal

src/jdk.hotspot.agent/doc/clhsdb.html line 35:

> 33:   classes <font color="red">print all loaded Java classes with Klass*</font>
> 34:   detach <font color="red">detach SA from current target</font>
> 35:   dis address [ length ]  <font color="red">disassemble (amd64) specified number of instructions from given address</font>

Two issues here. The first is I think this was previously incorrect in that SA supports any architecture for which it can find the hsdis library. You can probably just drop the amd64 reference or add "requires hsdis".

The 2nd issue is with amd64 vs x86_64. It seems in SA the two basically have the same meaning, and you see a lot of C code that checks for both. However, the java code seems to always just reference AMD64 (but also works with x86_64). I'm just wondering if this is consistent with the rest of hotspot, or if we should consider a rename to x86_64 instead of amd64.

BTW, at the platform level there are some amd64 vs x86_64 differences. The one I noted is that MacOSX is considered x86_64 and I think linux and windows are amd64. I'm not sure why, but I recently noted a test that had an @requires for `os.arch == "amd64"` and that kept is from running on macosx-x64 until the @requires was expanded to also allow for `os.arch == "x86_64"`.  You should take extra care to make sure that these changes work with all the x86_64, including macosx. I see some places in the C code where we check for both amd64 and x86_64 and some where we only check for amd64. Perhaps x86_64 is not used by SA for macosx.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2436821824

From lmesnik at openjdk.org  Thu Oct 16 18:37:47 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 16 Oct 2025 18:37:47 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <LeUal1WkcXO-KwIwtR950NQ3yFV27tYuLDc0GYjKCPc=.775d6ab5-3854-4f31-83ca-53a12ffa259e@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

The changes looks reasonable. I'm not familiar with ClassFile API though.

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

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25124#pullrequestreview-3346435277

From mark.reinhold at oracle.com  Thu Oct 16 19:18:24 2025
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Thu, 16 Oct 2025 19:18:24 +0000
Subject: New candidate JEP: 528: Post-Mortem Crash Analysis with jcmd
Message-ID: <20251016191614.B1C5C806@naskeag.niobe.net>

https://openjdk.org/jeps/528

  Summary: The jcmd tool supports the monitoring and troubleshooting
  of a running HotSpot JVM.  Extend jcmd so that it can also be used
  to diagnose a JVM that has crashed.  This will establish a consistent
  experience in both live and post-mortem environments.

- Mark

From pchilanomate at openjdk.org  Thu Oct 16 19:41:22 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 19:41:22 GMT
Subject: RFR: 8370036: TestJhsdbJstackWithVirtualThread.java fails when run
 with -showversion
Message-ID: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>

The test should use `launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-showversion"));` as is done with similar serviceability tests.

Thanks,
Patricio

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

Commit messages:
 - filter -showversion

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

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

From ayang at openjdk.org  Thu Oct 16 19:46:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Oct 2025 19:46:18 GMT
Subject: RFR: 8370036: TestJhsdbJstackWithVirtualThread.java fails when run
 with -showversion
In-Reply-To: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
References: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
Message-ID: <8l5BWWPO1G5eExVCmKWotMSHErtiOL4a1kKmEW2UCME=.918bd99f-e4ff-4eb7-9ece-202197a5f627@github.com>

On Thu, 16 Oct 2025 19:30:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> The test should use `launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-showversion"));` as is done with similar serviceability tests.
> 
> Thanks,
> Patricio

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27854#pullrequestreview-3346735250

From liach at openjdk.org  Thu Oct 16 19:49:17 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 Oct 2025 19:49:17 GMT
Subject: RFR: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests [v9]
In-Reply-To: <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
 <7i1SCVyMQFJFRG6paPJ947BsWhST_lYk6o_g_kyLlR8=.8e8b40b0-0778-49d8-b2e9-d0a1b771ce58@github.com>
Message-ID: <Fjp0vxsImvrQkoOHlEtyXhWkGrr5Ie2Gq7Kipk6JYEM=.845b1357-8124-4843-bc58-992aa36fc1e0@github.com>

On Wed, 15 Oct 2025 18:21:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
>> 
>> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
>> 
>> To avoid maintaining ASM down the road, we can either:
>> 1. Migrate the transformation to ClassFile API
>> 2. Set source and release version in javac flags to produce stable bytecode
>> 
>> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarification

Thanks for the reviews! This should remove the hassles associated with new javac class files from value objects in the future. Integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/25124#issuecomment-3412591019

From liach at openjdk.org  Thu Oct 16 19:49:18 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 16 Oct 2025 19:49:18 GMT
Subject: Integrated: 8356548: Use ClassFile API instead of ASM to transform
 classes in tests
In-Reply-To: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
References: <hW2vCD18gIA_jQZTwOkTHNxwsE6gCZfdWh3gKzvpa5M=.c52d7f54-e26b-44c2-b43f-0af07ad3add4@github.com>
Message-ID: <_itaIEjwLBQOzS5kpabor2UBk5jMpx0UeyaQsoNAPMU=.9b60c8d2-963d-4ad9-922d-23d637b9d881@github.com>

On Thu, 8 May 2025 14:57:05 GMT, Chen Liang <liach at openjdk.org> wrote:

> One of the goals of ClassFile API is to avoid updating the copy of ASM in the JDK (now moved to the test library) to support future class file formats.
> 
> However, some tests in hotspot turn out to parse latest class files, usually produced by the javac in the JDK under test, to transform them to inject desired bytecode patterns. If we keep these tests, we must keep maintaining the ASM library to accept all current class files, which will be costly with the upcoming project Valhalla.
> 
> To avoid maintaining ASM down the road, we can either:
> 1. Migrate the transformation to ClassFile API
> 2. Set source and release version in javac flags to produce stable bytecode
> 
> I recommend migrating to ClassFile API; javac has a deprecation policy, that in the future, old source and target versions will no longer be supported, and we would still need another port at that time.

This pull request has now been integrated.

Changeset: 3248aaf3
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3248aaf3c4f6784d5176e2a2c5bac0fbda47ee6b
Stats:     608 lines in 24 files changed: 92 ins; 302 del; 214 mod

8356548: Use ClassFile API instead of ASM to transform classes in tests

Reviewed-by: sspitsyn, lmesnik, coleenp, iklam

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

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

From ayang at openjdk.org  Thu Oct 16 20:09:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Oct 2025 20:09:19 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2]
In-Reply-To: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
Message-ID: <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>

> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
> 
> The failure rate is ~60% before the fix and no failure for 2000 runs.
> 
> Test: tier1-5

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into test-unload
 - copyright
 - review
 - test-unload

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27840/files
  - new: https://git.openjdk.org/jdk/pull/27840/files/36004136..49720706

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

  Stats: 2242 lines in 139 files changed: 1027 ins; 654 del; 561 mod
  Patch: https://git.openjdk.org/jdk/pull/27840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27840/head:pull/27840

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

From cjplummer at openjdk.org  Thu Oct 16 20:09:20 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 20:09:20 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2]
In-Reply-To: <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
 <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
Message-ID: <QfEdH6yHg7S3TfMH1hcmLtzI9oU7jjpWprK_Bw6_puE=.daa7474a-da7d-4fa5-bf19-bda790631863@github.com>

On Thu, 16 Oct 2025 20:05:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
>> 
>> The failure rate is ~60% before the fix and no failure for 2000 runs.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into test-unload
>  - copyright
>  - review
>  - test-unload

The changes look good. Copyrights need updating.

Thanks for providing the fix for this!

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27840#pullrequestreview-3346819019

From cjplummer at openjdk.org  Thu Oct 16 20:21:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 20:21:55 GMT
Subject: RFR: 8370036: TestJhsdbJstackWithVirtualThread.java fails when run
 with -showversion
In-Reply-To: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
References: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
Message-ID: <x-B_b0P46gW0BfEQuV8mfUqkQ6VQDnoGx-BBb6kTFGI=.e6a24fa9-8d82-4ad5-9bd9-e6cb57b85bb9@github.com>

On Thu, 16 Oct 2025 19:30:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> The test should use `launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-showversion"));` as is done with similar serviceability tests.
> 
> Thanks,
> Patricio

Looks good. Thanks for fixing!

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27854#pullrequestreview-3346866192

From pchilanomate at openjdk.org  Thu Oct 16 20:28:02 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 20:28:02 GMT
Subject: RFR: 8370036: TestJhsdbJstackWithVirtualThread.java fails when run
 with -showversion
In-Reply-To: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
References: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
Message-ID: <nREr2dOvWbLX-cdYgqQhwpsBwOn_iHVNhHu7003fDL0=.cc89371b-c410-49cf-82dc-2b1572adaeef@github.com>

On Thu, 16 Oct 2025 19:30:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> The test should use `launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-showversion"));` as is done with similar serviceability tests.
> 
> Thanks,
> Patricio

Thanks for the reviews Albert and Chris!
Is it okay to consider this as trivial?

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

PR Comment: https://git.openjdk.org/jdk/pull/27854#issuecomment-3412719884

From fandreuzzi at openjdk.org  Thu Oct 16 20:54:17 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 20:54:17 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - revert
 - replace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/b53c2da4..7870ca78

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

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

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

From pchilanomate at openjdk.org  Thu Oct 16 21:24:10 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 21:24:10 GMT
Subject: RFR: 8370036: TestJhsdbJstackWithVirtualThread.java fails when run
 with -showversion
In-Reply-To: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
References: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
Message-ID: <SYl_ihsltZra_13oxfsZVfg5FE_Eb0t6PkspUT-Zj14=.7781d6b9-0a13-490f-bb2c-25aaf68ee3af@github.com>

On Thu, 16 Oct 2025 19:30:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> The test should use `launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-showversion"));` as is done with similar serviceability tests.
> 
> Thanks,
> Patricio

Alright, I see the thumbs-up, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27854#issuecomment-3412900310

From pchilanomate at openjdk.org  Thu Oct 16 21:24:10 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 16 Oct 2025 21:24:10 GMT
Subject: Integrated: 8370036: TestJhsdbJstackWithVirtualThread.java fails when
 run with -showversion
In-Reply-To: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
References: <dbBk1UzTy6E-1PC7t-3qoVfB09hi67oiVvtwZII5O70=.e60fcaf9-06ba-4405-95c0-b4536dc04ec8@github.com>
Message-ID: <yynS00P_Lbc0Lo0d0U4R7aB0VNvYMzZs6FPXILGajxU=.42b5a5d9-83d1-4d80-9110-f73dab88fe0f@github.com>

On Thu, 16 Oct 2025 19:30:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> The test should use `launcher.addVMArgs(Utils.getFilteredTestJavaOpts("-showversion"));` as is done with similar serviceability tests.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 0c1c86e6
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0c1c86e68efcc140cefbde89b4d1d8708e931528
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8370036: TestJhsdbJstackWithVirtualThread.java fails when run with -showversion

Reviewed-by: ayang, cjplummer

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

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

From bpb at openjdk.org  Thu Oct 16 21:38:23 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Oct 2025 21:38:23 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
Message-ID: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>

Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

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

Commit messages:
 - 8369997: Tests that use custom scheduler should use jdk.test.lib.thread.VThreadScheduler

Changes: https://git.openjdk.org/jdk/pull/27855/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27855&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369997
  Stats: 69 lines in 3 files changed: 9 ins; 53 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/27855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27855/head:pull/27855

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

From bpb at openjdk.org  Thu Oct 16 21:38:24 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Oct 2025 21:38:24 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
References: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
Message-ID: <9HboOfUDk4418ghUH5KuXIqO-uKrhJlWcbJEvPBpdbM=.1a07fe3b-ac3e-44a9-bc76-7a3475a1a159@github.com>

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

The tests are copied from the [loom repository](https://github.com/openjdk/loom) with only minor cleanup of the import statements in two of the tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/27855#issuecomment-3412939050

From fandreuzzi at openjdk.org  Thu Oct 16 22:07:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 22:07:19 GMT
Subject: Integrated: 8369734: JvmtiExport::post_class_file_load_hook return
 value is never used
In-Reply-To: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
References: <p7TBBY9QFTdGzi4mWVBCe8g6Q4RRfKSJ8cZ0dNXctew=.a858ff1a-e290-4e04-bd84-90d733ee4567@github.com>
Message-ID: <CCHXj7CYxiEW0JmrlOoJJfC215qymBuB6guVx_5ydtQ=.1b02fb00-c5b8-41ad-9fc2-406ca198fe4d@github.com>

On Mon, 13 Oct 2025 22:26:42 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The return value of `JvmtiExport::post_class_file_load_hook` is never used, so we can remove the related dead code.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: 0bdd6f06
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0bdd6f0640fc25667f911228eed6a0fa118e8ff8
Stats:     12 lines in 2 files changed: 0 ins; 7 del; 5 mod

8369734: JvmtiExport::post_class_file_load_hook return value is never used

Reviewed-by: dholmes, sspitsyn

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

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

From sspitsyn at openjdk.org  Thu Oct 16 22:25:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 22:25:04 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2]
In-Reply-To: <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
 <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
Message-ID: <YaJNARoLt3X67pt8JC20C7lbtexvuZw2YgXL6jhoeKo=.76552e8f-d746-48de-a67b-45ef62ac3e6a@github.com>

On Thu, 16 Oct 2025 20:09:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
>> 
>> The failure rate is ~60% before the fix and no failure for 2000 runs.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into test-unload
>  - copyright
>  - review
>  - test-unload

Looks okay to me but I've posted a question.

test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 251:

> 249: 
> 250:         // force GC to unload marked class loader and its classes
> 251:         if (isClassLoaderReclaimed()) {

Q: There was a wait loop before to wait for `ClassLoader` to be reclaimed.
     How does this work now with the `isClassLoaderReclaimed()`?

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

PR Review: https://git.openjdk.org/jdk/pull/27840#pullrequestreview-3347195845
PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2437598897

From sspitsyn at openjdk.org  Thu Oct 16 22:37:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 22:37:01 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
Message-ID: <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>

On Thu, 16 Oct 2025 20:54:17 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert
>  - replace

The approach looks okay to me. Thank you for taking care about this issue!

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413122264

From sspitsyn at openjdk.org  Thu Oct 16 22:37:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 22:37:04 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
Message-ID: <MgoTrLCh3ke5OgC2olQe2JXqblZe1rzAxQYWZ0Zx_WM=.07410926-f3f0-4e7e-820d-4ee8dd331c31@github.com>

On Tue, 14 Oct 2025 21:34:42 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 38:
> 
>> 36: static void JNICALL VMStartJcmd(jvmtiEnv* jvmti, JNIEnv* env) {
>> 37:     char cmd[256];
>> 38:     snprintf(cmd, sizeof(cmd), "%s %d JVMTI.agent_load some.jar", getenv("JCMD_PATH"), PID());
> 
> Wouldn't be easier to have single env variable like ATTACH_CMD `.../bin/jcmd 45678 JVMTI.agent_load some.jar` which is completely set by java? So native code is simplified and there are less dependencies.

Also, I'd suggest to convert native part from C to C++. Some examples in the test base can be found easily. There is already a number of tests with C based native agents. We need to convert them to C++ at some point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2437610532

From fandreuzzi at openjdk.org  Thu Oct 16 22:54:35 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 22:54:35 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  check jcmd exist

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/7870ca78..1363424e

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

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

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

From cjplummer at openjdk.org  Thu Oct 16 22:56:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 16 Oct 2025 22:56:05 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2]
In-Reply-To: <YaJNARoLt3X67pt8JC20C7lbtexvuZw2YgXL6jhoeKo=.76552e8f-d746-48de-a67b-45ef62ac3e6a@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
 <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
 <YaJNARoLt3X67pt8JC20C7lbtexvuZw2YgXL6jhoeKo=.76552e8f-d746-48de-a67b-45ef62ac3e6a@github.com>
Message-ID: <18N33ct-KHbBGue5d06JiWxHnzgJeroB2rw-rViEs9A=.2d96bcef-b240-4750-8705-9124ba423109@github.com>

On Thu, 16 Oct 2025 22:21:19 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into test-unload
>>  - copyright
>>  - review
>>  - test-unload
>
> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 251:
> 
>> 249: 
>> 250:         // force GC to unload marked class loader and its classes
>> 251:         if (isClassLoaderReclaimed()) {
> 
> Q: There was a wait loop before to wait for `ClassLoader` to be reclaimed.
>      How does this work now with the `isClassLoaderReclaimed()`?

The previous approach relied on an async notification by the Cleaner thread that the class had been gc'd, so some waiting was needed (but probably not 15 seconds). There were also bugs in this support. unloadClass() is first called by the test to make sure that the class **does not** unload due to an intentional reference. This first call sets customClassLoader to null. That means when later unloadClass() is used again to this time make sure the class unloads, there will be no waiting, because for some reason unloadClass() chose to set waitingTime to 0 when customClassLoader is null. This meant that often unloadClass() would exit before the unloading completed. This is probably why the caller used to try up to 5 times. That left a race condition with the setting of is_reclaimed. It could be set sometime after unloadClass() finished and before it was entered again, but upon entry is_reclaimed is always set  to false, and it will never be set true again after that. Thus the test thinks
  the class never unloaded even though it did.

There are other ways to fix this issue (mainly always wait for 15 seconds and make sure unloadClass() always works on the first try). However, Albert's PhantomReference approach is a cleaner implementation and no longer relies waiting for some async process to complete the unloading of the class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2437639816

From amenkov at openjdk.org  Thu Oct 16 23:03:03 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 16 Oct 2025 23:03:03 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
Message-ID: <sHhxPH56yxv9XBVhOPwMyoLVZtI5ZeZ0asoQ1S7z9OI=.5c566fd8-17de-4de4-a41e-5ce325f47d17@github.com>

On Thu, 16 Oct 2025 22:54:35 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check jcmd exist

Looks like both new test fail on Windows-x64

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413173277

From sspitsyn at openjdk.org  Thu Oct 16 23:03:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:03:07 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
Message-ID: <MLDoiT0tq_xNY23GvtQRyvWwTl-S3iu6q9CiUZ-0fGg=.697028e3-61d3-4966-b11e-afcf707a6559@github.com>

On Thu, 16 Oct 2025 02:09:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The problemlist entries for incompatible tests are replaced with requires tag.
>> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
>> 
>> Tested by running these tests with virtual test tthread factory.
>
> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyrights updated
>  - more tests removed

The fix looks good in general but I've posted a question.

Marked as reviewed by sspitsyn (Reviewer).

test/jdk/ProblemList-Virtual.txt line 63:

> 61: java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
> 62: javax/management/ImplementationVersion/ImplVersionTest.java 0000000 generic-all
> 63: javax/management/remote/mandatory/version/ImplVersionTest.java 0000000 generic-all

Q: The following tests removed from this Problem-List do not have the required tweaks:

-java/lang/invoke/condy/CondyNestedResolutionTest.java
-jdk/jfr/startupargs/TestDumpOnExit.java
-java/util/Properties/StoreReproducibilityTest.java
-javax/management/ImplementationVersion/ImplVersionTest.java
-javax/management/remote/mandatory/version/ImplVersionTest.java

Is it intentional? Do I miss anything? Could you, please, explain a little bit?

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

PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3347252960
PR Review: https://git.openjdk.org/jdk/pull/27834#pullrequestreview-3347261953
PR Review Comment: https://git.openjdk.org/jdk/pull/27834#discussion_r2437646036

From sspitsyn at openjdk.org  Thu Oct 16 23:03:08 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:03:08 GMT
Subject: RFR: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead [v2]
In-Reply-To: <MLDoiT0tq_xNY23GvtQRyvWwTl-S3iu6q9CiUZ-0fGg=.697028e3-61d3-4966-b11e-afcf707a6559@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
 <8YJPBdfmNbvyKulHQW29vQgCoh4TJLHzo1CbanN_UC0=.7ef7521f-1daf-405a-aa90-fb18254f3699@github.com>
 <MLDoiT0tq_xNY23GvtQRyvWwTl-S3iu6q9CiUZ-0fGg=.697028e3-61d3-4966-b11e-afcf707a6559@github.com>
Message-ID: <tK2QZRmWg4m4UDLJIJpC-UG6i7wRrwf6qBaTrrKvFx4=.b321f19d-60c6-46e2-9aa1-79c907029c5b@github.com>

On Thu, 16 Oct 2025 22:57:34 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyrights updated
>>  - more tests removed
>
> test/jdk/ProblemList-Virtual.txt line 63:
> 
>> 61: java/util/Properties/StoreReproducibilityTest.java 0000000 generic-all
>> 62: javax/management/ImplementationVersion/ImplVersionTest.java 0000000 generic-all
>> 63: javax/management/remote/mandatory/version/ImplVersionTest.java 0000000 generic-all
> 
> Q: The following tests removed from this Problem-List do not have the required tweaks:
> 
> -java/lang/invoke/condy/CondyNestedResolutionTest.java
> -jdk/jfr/startupargs/TestDumpOnExit.java
> -java/util/Properties/StoreReproducibilityTest.java
> -javax/management/ImplementationVersion/ImplVersionTest.java
> -javax/management/remote/mandatory/version/ImplVersionTest.java
> 
> Is it intentional? Do I miss anything? Could you, please, explain a little bit?

I see you already explained this in the description. Sorry for the noise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27834#discussion_r2437658480

From fandreuzzi at openjdk.org  Thu Oct 16 23:10:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 23:10:02 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <sHhxPH56yxv9XBVhOPwMyoLVZtI5ZeZ0asoQ1S7z9OI=.5c566fd8-17de-4de4-a41e-5ce325f47d17@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
 <sHhxPH56yxv9XBVhOPwMyoLVZtI5ZeZ0asoQ1S7z9OI=.5c566fd8-17de-4de4-a41e-5ce325f47d17@github.com>
Message-ID: <6ICNwv-YCNa_BFoB4wYA2eyDE7cdNU4o1hG6rqLl-kY=.eb728477-b51c-497e-b821-d889db6ed4f5@github.com>

On Thu, 16 Oct 2025 23:00:46 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Looks like both new test fail on Windows-x64

I'm looking into it, I don't have a Windows setup so I'm using GHA to test :(

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413186002

From sspitsyn at openjdk.org  Thu Oct 16 23:11:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:11:07 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2]
In-Reply-To: <18N33ct-KHbBGue5d06JiWxHnzgJeroB2rw-rViEs9A=.2d96bcef-b240-4750-8705-9124ba423109@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
 <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
 <YaJNARoLt3X67pt8JC20C7lbtexvuZw2YgXL6jhoeKo=.76552e8f-d746-48de-a67b-45ef62ac3e6a@github.com>
 <18N33ct-KHbBGue5d06JiWxHnzgJeroB2rw-rViEs9A=.2d96bcef-b240-4750-8705-9124ba423109@github.com>
Message-ID: <eYXynrDSaux4uKZ1kLLB2R3uRqMyuoLXhw89D9uAeqg=.5cc89661-e167-4d85-bb36-4f00926014a8@github.com>

On Thu, 16 Oct 2025 22:53:00 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> test/hotspot/jtreg/vmTestbase/nsk/share/ClassUnloader.java line 251:
>> 
>>> 249: 
>>> 250:         // force GC to unload marked class loader and its classes
>>> 251:         if (isClassLoaderReclaimed()) {
>> 
>> Q: There was a wait loop before to wait for `ClassLoader` to be reclaimed.
>>      How does this work now with the `isClassLoaderReclaimed()`?
>
> The previous approach relied on an async notification by the Cleaner thread that the class had been gc'd, so some waiting was needed (but probably not 15 seconds). There were also bugs in this support. unloadClass() is first called by the test to make sure that the class **does not** unload due to an intentional reference. This first call sets customClassLoader to null. That means when later unloadClass() is used again to this time make sure the class unloads, there will be no waiting, because for some reason unloadClass() chose to set waitingTime to 0 when customClassLoader is null. This meant that often unloadClass() would exit before the unloading completed. This is probably why the caller used to try up to 5 times. That left a race condition with the setting of is_reclaimed. It could be set sometime after unloadClass() finished and before it was entered again, but upon entry is_reclaimed is always set  to false, and it will never be set true again after that. Thus the test thin
 ks the class never unloaded even though it did.
> 
> There are other ways to fix this issue (mainly always wait for 15 seconds and make sure unloadClass() always works on the first try). However, Albert's PhantomReference approach is a cleaner implementation and no longer relies waiting for some async process to complete the unloading of the class.

Okay. Thank you, Chris.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27840#discussion_r2437679608

From sspitsyn at openjdk.org  Thu Oct 16 23:11:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:11:05 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2]
In-Reply-To: <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
 <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
Message-ID: <Av6JHA0Pc7YS23PfhhMAz5penSKvJTzrOqZuot75OXc=.ddf4ff5d-632c-4894-b595-44e1fe00c9c9@github.com>

On Thu, 16 Oct 2025 20:09:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
>> 
>> The failure rate is ~60% before the fix and no failure for 2000 runs.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into test-unload
>  - copyright
>  - review
>  - test-unload

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27840#pullrequestreview-3347280549

From sspitsyn at openjdk.org  Thu Oct 16 23:13:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:13:01 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v4]
In-Reply-To: <bfplPYwHju2PIwPn5ZOz7OozCeaa8cGnTK9s2fFYhkI=.9a73eb01-be1d-4990-a924-bcea8a08c563@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <bfplPYwHju2PIwPn5ZOz7OozCeaa8cGnTK9s2fFYhkI=.9a73eb01-be1d-4990-a924-bcea8a08c563@github.com>
Message-ID: <ceMq5iXaP5z-nf9DPMzaEmibkcQH1OrKFAOY3UVaz-k=.7b665d31-24b3-4f28-ad1f-75f32a1a23a8@github.com>

On Thu, 16 Oct 2025 00:41:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test might fail with 
>> 
>> ----------System.out:(5/399)----------
>> The following fake exception stacktrace is for failure analysis.
>> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> at nsk_lvcomplain(nsk_tools.cpp:172)
>> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
>> 
>> if some of threads unexpectedly finishes during test execution. 
>> 
>> 
>> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - space added
>  - fix
>  - fixed applied

Thank you for update. Looks good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27831#pullrequestreview-3347287868

From sspitsyn at openjdk.org  Thu Oct 16 23:21:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:21:01 GMT
Subject: RFR: 8369924: Remove
 test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from
 problemlist
In-Reply-To: <XI76AQw-tLWmfzos1TpPPASZuq1FudzKxZb41dBjRAY=.a2b5dac8-582e-4973-b146-24a77967bf6e@github.com>
References: <XI76AQw-tLWmfzos1TpPPASZuq1FudzKxZb41dBjRAY=.a2b5dac8-582e-4973-b146-24a77967bf6e@github.com>
Message-ID: <NhjQMa94SenJ31mj3sDZRmolwFobr8sUe_rszDv6-CQ=.a32cbf67-37ab-481f-8bd8-e75fd3db23dd@github.com>

On Wed, 15 Oct 2025 15:45:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted, like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now. Key change may have been [JDK-8282726](https://bugs.openjdk.org/browse/JDK-8282726).
> 
> Remove from problem list.

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27825#pullrequestreview-3347310582

From sspitsyn at openjdk.org  Thu Oct 16 23:27:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 16 Oct 2025 23:27:00 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
References: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
Message-ID: <qL2zafgnwpZrtrPrOtSHxVgk9bnlXKWFi-u2kyv_Z-c=.e1aacfbb-7f7d-4399-84f7-5cffae128b81@github.com>

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

Looks good. Thank you for taking care about it.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27855#pullrequestreview-3347328531

From ysuenaga at openjdk.org  Thu Oct 16 23:33:02 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 16 Oct 2025 23:33:02 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute
In-Reply-To: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
Message-ID: <0U7NzjRnR5v68oV6Odf6yMCAavYV1hq14ER7rOaOQmE=.10030e43-cb75-4b03-bf2c-eba8a3ebeca7@github.com>

On Thu, 16 Oct 2025 13:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

AFAICS `RIP` points next instruction during subroutine call regardless whether it is `.cold` or not.  
I guess RIP points next `nop`  in compiler optimization for convenience because `abort` should not return, but I'm not sure.


(gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
   0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
=> 0x00007f50e1e01f33: nop
End of assembler dump.


Normally, address range (`start` - `start+size-1`) is ok because RIP should point top of instruction, however we should handle as special case of the function which has `.cold` suffix due to the reason in above.

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3413226882

From amenkov at openjdk.org  Fri Oct 17 00:33:08 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 17 Oct 2025 00:33:08 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v4]
In-Reply-To: <bfplPYwHju2PIwPn5ZOz7OozCeaa8cGnTK9s2fFYhkI=.9a73eb01-be1d-4990-a924-bcea8a08c563@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <bfplPYwHju2PIwPn5ZOz7OozCeaa8cGnTK9s2fFYhkI=.9a73eb01-be1d-4990-a924-bcea8a08c563@github.com>
Message-ID: <HRewcvxiZcN7QwvuQ41qWpHm36MSYB704yP0SpgXJn4=.2f0be23b-55d4-4ff8-9120-1c11bf438532@github.com>

On Thu, 16 Oct 2025 00:41:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test might fail with 
>> 
>> ----------System.out:(5/399)----------
>> The following fake exception stacktrace is for failure analysis.
>> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> at nsk_lvcomplain(nsk_tools.cpp:172)
>> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
>> 
>> if some of threads unexpectedly finishes during test execution. 
>> 
>> 
>> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - space added
>  - fix
>  - fixed applied

Changes requested by amenkov (Reviewer).

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp line 151:

> 149:         return NSK_FALSE;
> 150: 
> 151:     for (i = 0; i < debuggee_thread_cnt; i++) {

The fix looks incomplete.
There is global `threads_count` variable and it's used in a number of places in the file.
I think it would be simpler to add local `total_thread_count` and use it only to initialize `threadList` (`GetAllThreads`, allocate `threadList`, iteration through `threads`); `debuggee_thread_cnt` needs to be replaced with `threads_count`

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

PR Review: https://git.openjdk.org/jdk/pull/27831#pullrequestreview-3347562624
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2437900091

From dholmes at openjdk.org  Fri Oct 17 01:14:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 01:14:12 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]
In-Reply-To: <z0iqU4MgsvUh_B4IsEWwArMkz7h9aKKZ5RVJDbKPLKQ=.7ddc6d45-7ed8-4d54-a3a2-dbe997911bd7@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
 <z0iqU4MgsvUh_B4IsEWwArMkz7h9aKKZ5RVJDbKPLKQ=.7ddc6d45-7ed8-4d54-a3a2-dbe997911bd7@github.com>
Message-ID: <6YqJmhccFDBabVIQpN3nNt_Cpa1zNQg3rRvtiTCEJmo=.c3653095-8ae3-4f0d-8c3b-50d4109b4b69@github.com>

On Thu, 16 Oct 2025 17:24:35 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>>  - Clean up Hotspot SA after 32-bit x86 removal
>
> src/jdk.hotspot.agent/doc/clhsdb.html line 35:
> 
>> 33:   classes <font color="red">print all loaded Java classes with Klass*</font>
>> 34:   detach <font color="red">detach SA from current target</font>
>> 35:   dis address [ length ]  <font color="red">disassemble (amd64) specified number of instructions from given address</font>
> 
> Two issues here. The first is I think this was previously incorrect in that SA supports any architecture for which it can find the hsdis library. You can probably just drop the amd64 reference or add "requires hsdis".
> 
> The 2nd issue is with amd64 vs x86_64. It seems in SA the two basically have the same meaning, and you see a lot of C code that checks for both. However, the java code seems to always just reference AMD64 (but also works with x86_64). I'm just wondering if this is consistent with the rest of hotspot, or if we should consider a rename to x86_64 instead of amd64.
> 
> BTW, at the platform level there are some amd64 vs x86_64 differences. The one I noted is that MacOSX is considered x86_64 and I think linux and windows are amd64. I'm not sure why, but I recently noted a test that had an @requires for `os.arch == "amd64"` and that kept is from running on macosx-x64 until the @requires was expanded to also allow for `os.arch == "x86_64"`.  You should take extra care to make sure that these changes work with all the x86_64, including macosx. I see some places in the C code where we check for both amd64 and x86_64 and some where we only check for amd64. Perhaps x86_64 is not used by SA for macosx.

AMD64 is historical, it should all be changed to x86_64. The only place AMD64 is relevant is in actual AMD processor specific code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2437959110

From dholmes at openjdk.org  Fri Oct 17 01:23:09 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 01:23:09 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]
In-Reply-To: <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
Message-ID: <BvqDhcPQSizZF3vwrZodeWK3PblOLDdn4u1pkJhjal0=.7019cfe8-b2ae-4280-b20f-a8c6b16b864e@github.com>

On Thu, 16 Oct 2025 13:58:09 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into clean-x86-sa-JDK-8351194
>  - Clean up Hotspot SA after 32-bit x86 removal

Eradicating all references to amd64 is probably worthwhile but a larger undertaking. For now changing x86 (implied 32-bit) to amd64, seems reasonable to me.

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

PR Review: https://git.openjdk.org/jdk/pull/27844#pullrequestreview-3347645759

From lmesnik at openjdk.org  Fri Oct 17 02:19:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 02:19:35 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v5]
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <y477SI9Dc-kIxE0_yM_IF9C8oX0GQ68tdPDMRzG5AYA=.bb2042f8-7580-4e5d-96f1-0496d278bed8@github.com>

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  the count variables are corrected

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27831/files
  - new: https://git.openjdk.org/jdk/pull/27831/files/e70b8841..4833e33b

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

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

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

From lmesnik at openjdk.org  Fri Oct 17 02:22:18 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 02:22:18 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v4]
In-Reply-To: <HRewcvxiZcN7QwvuQ41qWpHm36MSYB704yP0SpgXJn4=.2f0be23b-55d4-4ff8-9120-1c11bf438532@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <bfplPYwHju2PIwPn5ZOz7OozCeaa8cGnTK9s2fFYhkI=.9a73eb01-be1d-4990-a924-bcea8a08c563@github.com>
 <HRewcvxiZcN7QwvuQ41qWpHm36MSYB704yP0SpgXJn4=.2f0be23b-55d4-4ff8-9120-1c11bf438532@github.com>
Message-ID: <UI_4HbJIcXZipXFcNGrl8h5R7ImLAcL14G8CgouuRJI=.ee7d84bc-2867-412b-b4e7-a8543aa0a97c@github.com>

On Fri, 17 Oct 2025 00:29:41 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - space added
>>  - fix
>>  - fixed applied
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp line 151:
> 
>> 149:         return NSK_FALSE;
>> 150: 
>> 151:     for (i = 0; i < debuggee_thread_cnt; i++) {
> 
> The fix looks incomplete.
> There is global `threads_count` variable and it's used in a number of places in the file.
> I think it would be simpler to add local `total_thread_count` and use it only to initialize `threadList` (`GetAllThreads`, allocate `threadList`, iteration through `threads`); `debuggee_thread_cnt` needs to be replaced with `threads_count`

Thank you! You are correct, the `debuggee_thread_cnt` is made global and used while printing locks.
I also renamed it to  `debuggee_threads_cnt`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2438036929

From lmesnik at openjdk.org  Fri Oct 17 02:29:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 02:29:35 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v6]
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <o0Naj-SeivOoSILJPzLYIyO0K7Pn_PLkVrw8GGCKROY=.ea810e9f-2f72-418c-ab2a-89fd364b7cfc@github.com>

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  renamed threadList

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27831/files
  - new: https://git.openjdk.org/jdk/pull/27831/files/4833e33b..954fc280

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

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

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

From alanb at openjdk.org  Fri Oct 17 06:07:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 06:07:01 GMT
Subject: RFR: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
References: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
Message-ID: <hlbZn8WC1qaXqVOuY20JxFvd3JF_JXvrvQt_V4HCFq8=.d0225cee-95c3-4d48-a1d6-43f48680eaf1@github.com>

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

Thanks for doing this, these test changes have been sitting in the loom repo for a long time.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27855#pullrequestreview-3348423461

From cjplummer at openjdk.org  Fri Oct 17 06:19:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 Oct 2025 06:19:05 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v6]
In-Reply-To: <o0Naj-SeivOoSILJPzLYIyO0K7Pn_PLkVrw8GGCKROY=.ea810e9f-2f72-418c-ab2a-89fd364b7cfc@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <o0Naj-SeivOoSILJPzLYIyO0K7Pn_PLkVrw8GGCKROY=.ea810e9f-2f72-418c-ab2a-89fd364b7cfc@github.com>
Message-ID: <cdVzXvIn_NnK9Khpjk96Wq0J3xfi77MWmzqAubpNSmg=.9ce8cfdd-13c6-4b72-a8ed-3c17b3ce6475@github.com>

On Fri, 17 Oct 2025 02:29:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test might fail with 
>> 
>> ----------System.out:(5/399)----------
>> The following fake exception stacktrace is for failure analysis.
>> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> at nsk_lvcomplain(nsk_tools.cpp:172)
>> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
>> 
>> if some of threads unexpectedly finishes during test execution. 
>> 
>> 
>> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed threadList

Marked as reviewed by cjplummer (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27831#pullrequestreview-3348458287

From kevinw at openjdk.org  Fri Oct 17 08:19:17 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Oct 2025 08:19:17 GMT
Subject: RFR: 8369924: Remove
 test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from
 problemlist
In-Reply-To: <XI76AQw-tLWmfzos1TpPPASZuq1FudzKxZb41dBjRAY=.a2b5dac8-582e-4973-b146-24a77967bf6e@github.com>
References: <XI76AQw-tLWmfzos1TpPPASZuq1FudzKxZb41dBjRAY=.a2b5dac8-582e-4973-b146-24a77967bf6e@github.com>
Message-ID: <4Sxh6kQH-CIsr935Qq5RvKTyxg5xLVdJ-xbVio-wfEM=.892a9115-919c-4c91-bb99-a702b805f66d@github.com>

On Wed, 15 Oct 2025 15:45:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted, like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now. Key change may have been [JDK-8282726](https://bugs.openjdk.org/browse/JDK-8282726).
> 
> Remove from problem list.

Thanks Serguei!

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

PR Comment: https://git.openjdk.org/jdk/pull/27825#issuecomment-3414364269

From kevinw at openjdk.org  Fri Oct 17 08:19:18 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Oct 2025 08:19:18 GMT
Subject: Integrated: 8369924: Remove
 test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from
 problemlist
In-Reply-To: <XI76AQw-tLWmfzos1TpPPASZuq1FudzKxZb41dBjRAY=.a2b5dac8-582e-4973-b146-24a77967bf6e@github.com>
References: <XI76AQw-tLWmfzos1TpPPASZuq1FudzKxZb41dBjRAY=.a2b5dac8-582e-4973-b146-24a77967bf6e@github.com>
Message-ID: <h_0x5fb-hl072zu17CHSp3acoo3cd28ZAIFd76L9kVY=.f09c4bb8-b353-4d31-ae90-764ac45c1f6e@github.com>

On Wed, 15 Oct 2025 15:45:25 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted, like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now. Key change may have been [JDK-8282726](https://bugs.openjdk.org/browse/JDK-8282726).
> 
> Remove from problem list.

This pull request has now been integrated.

Changeset: a22438dd
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a22438ddc5949fcfb6f773bd8dc080cd8a1f2710
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8369924: Remove test/jdk/javax/management/remote/mandatory/loading/MissingClassTest.java from problemlist

Reviewed-by: sspitsyn

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

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

From coffeys at openjdk.org  Fri Oct 17 08:58:46 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 17 Oct 2025 08:58:46 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message
Message-ID: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>

Simple tweak to jcmd Thread.print help message

jdk_svc test group ran and green

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

Commit messages:
 - 8370071

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

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

From ayang at openjdk.org  Fri Oct 17 09:05:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:05:21 GMT
Subject: RFR: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded [v2]
In-Reply-To: <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
 <xJe_wkkba_QvlT6YVjibkVreg1hBSHGBuGtxjVXXEjw=.a69e5abe-7400-4a73-b7a1-39157881e45b@github.com>
Message-ID: <wNe9jxKcYjFmrD5uXKgv4mJ__CWuwDvc3fM5BQjWuNY=.e09d51b4-eaf7-4641-9c3d-f13cc2b2a0d0@github.com>

On Thu, 16 Oct 2025 20:09:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
>> 
>> The failure rate is ~60% before the fix and no failure for 2000 runs.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into test-unload
>  - copyright
>  - review
>  - test-unload

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27840#issuecomment-3414524556

From ayang at openjdk.org  Fri Oct 17 09:05:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:05:22 GMT
Subject: Integrated: 8342659: Test
 vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java
 failed: Class nsk.share.jdi.TestClass1 was not unloaded
In-Reply-To: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
References: <VeICdIfOoHsujvGw1gjsW6tkHbj-Bk2mavBTSQUy0eE=.d0efba57-ff94-4685-a71f-18fbd1380a5b@github.com>
Message-ID: <TXUViZd2bbQO4grOMg9vH10D9IpJek5XoatkLHpzX9E=.7e6e6750-64fb-4276-91b2-2105d1eff34d@github.com>

On Thu, 16 Oct 2025 09:25:42 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Use `Reference.refersTo` API to get more up to date liveness info of a class after OOM is thrown. The approach of relying `Cleaner` thread can incur some "asynchronous" cause various retrying logic, complicating the flow.
> 
> The failure rate is ~60% before the fix and no failure for 2000 runs.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: e62a7fa3
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e62a7fa3832bbba11e6d630015f85ae945fac824
Stats:     54 lines in 2 files changed: 8 ins; 37 del; 9 mod

8342659: Test vmTestbase/nsk/jdi/ObjectReference/referringObjects/referringObjects002/referringObjects002.java failed: Class nsk.share.jdi.TestClass1 was not unloaded

Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Reviewed-by: sspitsyn, cjplummer

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

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

From coffeys at openjdk.org  Fri Oct 17 09:08:26 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 17 Oct 2025 09:08:26 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message
In-Reply-To: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
Message-ID: <aBeWUi_BPmMgzhQ2Dy7p9sEz2RMPk9B9Izb9RBtyRDI=.a8312a24-7104-482f-b2d7-1ba78750d8f6@github.com>

On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Simple tweak to jcmd Thread.print help message
> 
> jdk_svc test group ran and green

Any issues if I add this sentence to the help output ?

?Use Thread.dump_to_file command for extended threads detail including virtual thread information."

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

PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414538711

From kevinw at openjdk.org  Fri Oct 17 09:23:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Oct 2025 09:23:04 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message
In-Reply-To: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
Message-ID: <-VovWtoXXm8Kss1SHjKHRCz0FKzUZLYHmDBZBYgLB3g=.50926ddd-c403-4ef7-9dc4-cbad57466244@github.com>

On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Simple tweak to jcmd Thread.print help message
> 
> jdk_svc test group ran and green

Good idea, this could be clearer.

If you want to expand this: 
Elsewhere for ThreadDumpToFileDCmd we say:
"Dump threads, with stack traces, to a file in plain text or JSON format."
We could add on: "Includes virtual threads." or add in that fact somehow.

There's also a man page ./src/jdk.jcmd/share/man/jcmd.md where we have the same text for both commands.  8-)

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27861#pullrequestreview-3349068624

From alanb at openjdk.org  Fri Oct 17 09:34:07 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 09:34:07 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message
In-Reply-To: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
Message-ID: <OFLYpwwo7NoPo8ZRYhQdxG_FPMFUwiDbxlfctB234tA=.7df837ad-9edb-4588-97f5-bb2e266a013b@github.com>

On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Simple tweak to jcmd Thread.print help message
> 
> jdk_svc test group ran and green

src/hotspot/share/services/diagnosticCommand.hpp line 359:

> 357:   static const char* name() { return "Thread.print"; }
> 358:   static const char* description() {
> 359:     return "Print all platform threads with stacktraces.";

The Thread.print section of the jcmd man page can be updated to align with the update description.

If there is space, then it include "all mounted virtual threads".

(Note that there was a previous attempt to change this description when the Thread.print was updated to include mounted virtual threads. At the time, the PR feedback was to separate it to a different PR but there wasn't any follow-up on that so good to see it re-visited here)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439015833

From ayang at openjdk.org  Fri Oct 17 09:56:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:56:47 GMT
Subject: RFR: 8370074: Remove unused code in AbstractDebuggeeTest.java
Message-ID: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>

Trivial removing dead code.

Test: tier1

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

Commit messages:
 - vmtestbase-trivial

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

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

From coffeys at openjdk.org  Fri Oct 17 10:05:39 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 17 Oct 2025 10:05:39 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2]
In-Reply-To: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
Message-ID: <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>

> Simple tweak to jcmd Thread.print help message
> 
> jdk_svc test group ran and green

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  man page and better help messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27861/files
  - new: https://git.openjdk.org/jdk/pull/27861/files/b7c0a1ba..4d2e42aa

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

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

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

From coffeys at openjdk.org  Fri Oct 17 10:05:41 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 17 Oct 2025 10:05:41 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2]
In-Reply-To: <-VovWtoXXm8Kss1SHjKHRCz0FKzUZLYHmDBZBYgLB3g=.50926ddd-c403-4ef7-9dc4-cbad57466244@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <-VovWtoXXm8Kss1SHjKHRCz0FKzUZLYHmDBZBYgLB3g=.50926ddd-c403-4ef7-9dc4-cbad57466244@github.com>
Message-ID: <Sx5Wm5S3N7nxuc7oIFXLCuPvZMZi4Ebl6-x0ksvo4bM=.585e4ea8-32c4-42be-8e1c-f9ec21d6040b@github.com>

On Fri, 17 Oct 2025 09:20:17 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Good idea, this could be clearer.
> 
> If you want to expand this: Elsewhere for ThreadDumpToFileDCmd we say: "Dump threads, with stack traces, to a file in plain text or JSON format." We could add on: "Includes virtual threads." or add in that fact somehow.
> 
> There's also a man page ./src/jdk.jcmd/share/man/jcmd.md where we have the same text for both commands. 8-)

Thanks for the man page reminder Kevin. I've added some extra help information also. I think it'll help guide users of these tools. PR updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414735179

From kevinw at openjdk.org  Fri Oct 17 10:16:59 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Oct 2025 10:16:59 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2]
In-Reply-To: <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
Message-ID: <A0d-M9XvfID98MTsffPa5JFInQEtMld6BH3jWC4rKkw=.cb80fe5f-d153-40ad-a273-1c36ecab5926@github.com>

On Fri, 17 Oct 2025 10:05:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to jcmd Thread.print help message
>> 
>> jdk_svc test group ran and green
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   man page and better help messages

Saying "extended threads detail", or even "extended thread details" is a bit vague.  It's not clear what Thread.print misses out, or if this will always be true.  Could it be just: "Use Thread.dump_to_file for virtual thread information."

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

PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414789848

From alanb at openjdk.org  Fri Oct 17 10:17:02 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Oct 2025 10:17:02 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2]
In-Reply-To: <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
Message-ID: <7BRnnoYhHBzwcYZkKLVtBPiRFIh96owSKtyxj98Fde4=.fc5196dd-b438-4233-9fb5-5bc181fc361e@github.com>

On Fri, 17 Oct 2025 10:05:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to jcmd Thread.print help message
>> 
>> jdk_svc test group ran and green
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   man page and better help messages

src/hotspot/share/services/diagnosticCommand.hpp line 361:

> 359:     return "Print all platform threads with stacktraces. "
> 360:            "Use Thread.dump_to_file command for extended threads "
> 361:             "detail including virtual thread information.";

Can you try "Print all platform threads, and mounted virtual threads, with stack traces"?

Not sure about the second line. I assume you are proposing to add this in order to created awareness but saying "extended threads detail" is confusing. If a second line is added then it could be very simple, e.g. "The Thread.dump_to_file command will print all threads to a file".

src/hotspot/share/services/diagnosticCommand.hpp line 773:

> 771:   }
> 772:   static const char *description() {
> 773:     return "Dump threads (including virtual), with stack traces, "

If you change it to "Dump all threads" then it would be simpler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439162626
PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439140850

From coffeys at openjdk.org  Fri Oct 17 10:25:43 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 17 Oct 2025 10:25:43 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2]
In-Reply-To: <7BRnnoYhHBzwcYZkKLVtBPiRFIh96owSKtyxj98Fde4=.fc5196dd-b438-4233-9fb5-5bc181fc361e@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
 <7BRnnoYhHBzwcYZkKLVtBPiRFIh96owSKtyxj98Fde4=.fc5196dd-b438-4233-9fb5-5bc181fc361e@github.com>
Message-ID: <OkoFS9xGFmcXLlqGD6ikto0nObG6Pzx6DzbPNwUT_oQ=.d10cb7fa-e452-4940-9049-3e877cb47f7a@github.com>

On Fri, 17 Oct 2025 10:14:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   man page and better help messages
>
> src/hotspot/share/services/diagnosticCommand.hpp line 361:
> 
>> 359:     return "Print all platform threads with stacktraces. "
>> 360:            "Use Thread.dump_to_file command for extended threads "
>> 361:             "detail including virtual thread information.";
> 
> Can you try "Print all platform threads, and mounted virtual threads, with stack traces"?
> 
> Not sure about the second line. I assume you are proposing to add this in order to created awareness but saying "extended threads detail" is confusing. If a second line is added then it could be very simple, e.g. "The Thread.dump_to_file command will print all threads to a file".

yes - nice to have the "mounted virtual threads" clarity. 

"The Thread.dump_to_file command will print all threads to a file". --> Will run with that. thanks.

I think it's useful to hint at these commands when end users are reading such help messages.
(e.g. "I want to print thread information but this command is telling me I only get platform + mounted threads.. what do I use for all threads etc.")

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2439203942

From coffeys at openjdk.org  Fri Oct 17 10:25:39 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 17 Oct 2025 10:25:39 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2]
In-Reply-To: <A0d-M9XvfID98MTsffPa5JFInQEtMld6BH3jWC4rKkw=.cb80fe5f-d153-40ad-a273-1c36ecab5926@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
 <A0d-M9XvfID98MTsffPa5JFInQEtMld6BH3jWC4rKkw=.cb80fe5f-d153-40ad-a273-1c36ecab5926@github.com>
Message-ID: <NP52DkTsc-K2_RqmhHdOg6M9Ww-N-pJEHIBMwwTpcBg=.b8115431-3e8e-40f4-a033-3133e112b1d0@github.com>

On Fri, 17 Oct 2025 10:12:12 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Saying "extended threads detail", or even "extended thread details" is a bit vague. It's not clear what Thread.print misses out, or if this will always be true. Could it be just: "Use Thread.dump_to_file for virtual thread information."

Yes - that's a fair point. The dump_to_file option also prints j.u.c Lock information for virtual theads. (hence extended)
Thread.print prints details of a virtual thread if it's mounted. 

but yes, "Use Thread.dump_to_file for virtual thread information." sounds better. Maybe even ""Use Thread.dump_to_file for all thread information." based on Alan's comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414827799

From kevinw at openjdk.org  Fri Oct 17 10:31:10 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Oct 2025 10:31:10 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v2]
In-Reply-To: <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <ltO0aazliLNMzliBN8VVj-IN1MRSz1COmi-v_Qu0dCQ=.3f386ad1-e73d-4c0d-860c-3dd808a430a9@github.com>
Message-ID: <nFQZ_Y-OuM2QfyYCb5RIH5X51fglSLbUIXpXKQAnJzY=.2c1e6dad-bee7-474c-9ac5-e6c5e5e8e42d@github.com>

On Fri, 17 Oct 2025 10:05:39 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to jcmd Thread.print help message
>> 
>> jdk_svc test group ran and green
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   man page and better help messages

By: "Use Thread.dump_to_file for all thread information." 
do we mean:
"Use Thread.dump_to_file for information on all threads."

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

PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3414868872

From coffeys at openjdk.org  Fri Oct 17 11:11:19 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 17 Oct 2025 11:11:19 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3]
In-Reply-To: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
Message-ID: <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>

> Simple tweak to jcmd Thread.print help message
> 
> jdk_svc test group ran and green

Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:

  Further help message tweaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27861/files
  - new: https://git.openjdk.org/jdk/pull/27861/files/4d2e42aa..1d688320

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

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

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

From kevinw at openjdk.org  Fri Oct 17 11:15:02 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Oct 2025 11:15:02 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3]
In-Reply-To: <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>
Message-ID: <X9wLTgNSjPE2f83R1RWUyNQlcKezvQcqtsxyFbDaupA=.112dfd86-bb65-4155-8c53-1a423f57db52@github.com>

On Fri, 17 Oct 2025 11:11:19 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to jcmd Thread.print help message
>> 
>> jdk_svc test group ran and green
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further help message tweaks

Marked as reviewed by kevinw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27861#pullrequestreview-3349589749

From fandreuzzi at openjdk.org  Fri Oct 17 13:44:06 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 13:44:06 GMT
Subject: RFR: 8370074: Remove unused code in AbstractDebuggeeTest.java
In-Reply-To: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
References: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
Message-ID: <KfHf4gTkzgU_GEN8JiBwBNaAZk91hetvkdK72J6cVbE=.3e695428-b21d-4196-b19f-f285df188aa4@github.com>

On Fri, 17 Oct 2025 09:48:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27863#pullrequestreview-3350431589

From bpb at openjdk.org  Fri Oct 17 15:15:22 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Oct 2025 15:15:22 GMT
Subject: Integrated: 8369997: Tests that use custom scheduler should use
 jdk.test.lib.thread.VThreadScheduler
In-Reply-To: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
References: <SY255LC7-wDtV52g_A1eErfISwDTpXB0Y-y_7qj5hRY=.1a3faff2-8e5a-4730-9541-5072676ffb8d@github.com>
Message-ID: <u7slGzVXJJx6gexQXTM9k5a8MZYaYQ5QI4WzMm4lIKQ=.fa2be57e-a906-437b-85f4-f1e7ced093e5@github.com>

On Thu, 16 Oct 2025 21:31:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Straightforward update of some tests which use core reflection to set the `Thread.Builder` scheduler.

This pull request has now been integrated.

Changeset: cc6f8f13
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc6f8f1307476886aa3c43a2b966fc7bff2be04e
Stats:     69 lines in 3 files changed: 9 ins; 53 del; 7 mod

8369997: Tests that use custom scheduler should use jdk.test.lib.thread.VThreadScheduler

Reviewed-by: sspitsyn, alanb

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

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

From lmesnik at openjdk.org  Fri Oct 17 16:06:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 16:06:43 GMT
Subject: Integrated: 8348844: Remove remaining JVMTI tests from
 ProblemList-Virtual, use requires instead
In-Reply-To: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
References: <ODQsqhLJzFHRDQ2CjFefJAftKt0Jft7VJlY-xE5Uhoo=.7f2e5b53-98ca-47c1-a3fc-2c5b9e00c11e@github.com>
Message-ID: <w9pTTU-3WfN9vkz-sRQzcJi4Gbpp_ZEvGn-MYj5vELM=.ca9da0a0-7d81-47a3-b219-2da962345e43@github.com>

On Thu, 16 Oct 2025 01:55:09 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The problemlist entries for incompatible tests are replaced with requires tag.
> Some tests (permissions-related) are not failing anymore. So they are just removed from the problemlist.
> 
> Tested by running these tests with virtual test tthread factory.

This pull request has now been integrated.

Changeset: 28bf9176
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28bf9176b8d460242bb7cedfb3bde5c6294c56fb
Stats:     70 lines in 18 files changed: 17 ins; 38 del; 15 mod

8348844: Remove remaining JVMTI tests from ProblemList-Virtual, use requires instead

Reviewed-by: dholmes, alanb, syan, sspitsyn

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

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

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:02 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v10]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with 10 additional commits since the last revision:

 - c++
 - cc
 - simplfiy
 - mv to attach
 - revert
 - debug
 - backslash
 - quote
 - revert
 - wip

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/1363424e..1af09f8b

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

  Stats: 350 lines in 5 files changed: 146 ins; 204 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

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

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:08 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:08 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
Message-ID: <F1N3phFNxogMDSXk4SsN3kRAucfut4cacCBt8-HBeuc=.034dacc6-084d-4550-b9a6-d080b0116628@github.com>

On Tue, 14 Oct 2025 21:31:47 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadAttach.java line 40:
> 
>> 38: import jdk.test.lib.JDKToolFinder;
>> 39: 
>> 40: public class TestEarlyDynamicLoadAttach {
> 
> We don't usually have individual tests on the 'serviceability' level. 
> Please move test into 'attach' folder. It is test for fix in the attach mechanism.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2440491128

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:10 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:10 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <MgoTrLCh3ke5OgC2olQe2JXqblZe1rzAxQYWZ0Zx_WM=.07410926-f3f0-4e7e-820d-4ee8dd331c31@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <mjtNKUf1r0f0mxwGdoZSrQO9uvUS6MCUdaMu3U_Q3co=.b45c0abb-68b3-435d-adfa-858c83c0ddd5@github.com>
 <MgoTrLCh3ke5OgC2olQe2JXqblZe1rzAxQYWZ0Zx_WM=.07410926-f3f0-4e7e-820d-4ee8dd331c31@github.com>
Message-ID: <9mUt6vbiBvvOJ--6txTUob5bD1f-DGXRUoMDcxjLi-8=.f491c8e1-e4a8-4650-a5d7-4842b7cc99d0@github.com>

On Thu, 16 Oct 2025 22:29:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 38:
>> 
>>> 36: static void JNICALL VMStartJcmd(jvmtiEnv* jvmti, JNIEnv* env) {
>>> 37:     char cmd[256];
>>> 38:     snprintf(cmd, sizeof(cmd), "%s %d JVMTI.agent_load some.jar", getenv("JCMD_PATH"), PID());
>> 
>> Wouldn't be easier to have single env variable like ATTACH_CMD `.../bin/jcmd 45678 JVMTI.agent_load some.jar` which is completely set by java? So native code is simplified and there are less dependencies.
>
> Also, I'd suggest to convert native part from C to C++. Some examples in the test base can be found easily. There is already a number of tests with C based native agents. We need to convert them to C++ at some point.

Thanks for the suggestion, I changed the test structure so this is not applicable anymore.

Also, converted the native part to c++: 1af09f8ba080416b94aeb947da3a6be1acf9167d

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2440490778

From dholmes at openjdk.org  Fri Oct 17 16:13:05 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 16:13:05 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v9]
In-Reply-To: <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <W5LLmYwVSVN8aMoqgwMK1q6DaEjkUkQju_OVnL9sPJ0=.34a8ca87-dff2-4e81-bb6b-73d7a0841144@github.com>
Message-ID: <f11QojUuRje2OV27YBL71LVkpLe--v9ExYMMBs2r-P0=.b25ea331-26ba-4d08-9f4d-7ddcea7c0e0c@github.com>

On Thu, 16 Oct 2025 22:54:35 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check jcmd exist

Note that while a PR is in draft mode, no emails get generated.

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3413501278

From dholmes at openjdk.org  Fri Oct 17 16:13:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 17 Oct 2025 16:13:11 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v10]
In-Reply-To: <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>
Message-ID: <EocRJcw6B_A2HIkrX82TqA-D6Q_yykHeURbVoogQHWY=.79f593e0-4b62-4704-999e-6f81f3ec0c88@github.com>

On Fri, 17 Oct 2025 16:09:54 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - c++
>  - cc
>  - simplfiy
>  - mv to attach
>  - revert
>  - debug
>  - backslash
>  - quote
>  - revert
>  - wip

test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 48:

> 46: 
> 47:     char cmd[256];
> 48:     snprintf(cmd, sizeof(cmd), "%s %d help", jcmd_path, PID());

Why are you running the help command instead of `agent_load` ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2438017610

From fandreuzzi at openjdk.org  Fri Oct 17 16:13:13 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:13:13 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v10]
In-Reply-To: <EocRJcw6B_A2HIkrX82TqA-D6Q_yykHeURbVoogQHWY=.79f593e0-4b62-4704-999e-6f81f3ec0c88@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <1XSnqjFkvyuTJlXFWXsWT_RMjELiBQto3dZ6cJ3TeKU=.b40e084f-ef19-4d53-96a1-ff8241bfe550@github.com>
 <EocRJcw6B_A2HIkrX82TqA-D6Q_yykHeURbVoogQHWY=.79f593e0-4b62-4704-999e-6f81f3ec0c88@github.com>
Message-ID: <FhQbA7apcARR_HccYovc4QpGtHl6pH6kPDwhLTZUDKc=.e668c548-e185-4799-a206-52e1095e07cf@github.com>

On Fri, 17 Oct 2025 02:04:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - c++
>>  - cc
>>  - simplfiy
>>  - mv to attach
>>  - revert
>>  - debug
>>  - backslash
>>  - quote
>>  - revert
>>  - wip
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/libEarlyDynamicLoad.c line 48:
> 
>> 46: 
>> 47:     char cmd[256];
>> 48:     snprintf(cmd, sizeof(cmd), "%s %d help", jcmd_path, PID());
> 
> Why are you running the help command instead of `agent_load` ???

See my [earlier comment](https://github.com/openjdk/jdk/pull/27766/#issuecomment-3413186002), I'm debugging failures on Windows so my code isn't in a reviewable state. Thus why I marked the PR as draft.

I'll make it ready again as soon as I fix the tests on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2438756587

From fandreuzzi at openjdk.org  Fri Oct 17 16:20:11 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:20:11 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v2]
In-Reply-To: <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gwrFvqAE4TERPqDugxR3MLQFWsmq3bJn426YC5fgUN0=.661467a3-64c8-4e46-beaf-77b2a7c1486d@github.com>
 <5h-R58p6ZHYpOQjGkuDJ_JBnlVpWArClkwYtooSjFkE=.1f1361e5-8424-4161-9a7a-4f4b91f45f48@github.com>
Message-ID: <0SdjN96JipADAZBtK9PznSyfjpNvMyKgDL2mbk9iR4s=.b139b787-8776-4f52-9d0d-30e934bf8d36@github.com>

On Thu, 16 Oct 2025 08:27:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   summary
>
> test/hotspot/jtreg/serviceability/EarlyDynamicLoad/TestEarlyDynamicLoadJcmd.java line 50:
> 
>> 48: 
>> 49:         OutputAnalyzer output = new OutputAnalyzer(pb.start());
>> 50:         output.shouldHaveExitValue(0);
> 
> Yes but more importantly we should be checking for the "not in live phase" error message.

Fixed in the latest revision

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2440519881

From cjplummer at openjdk.org  Fri Oct 17 16:24:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 17 Oct 2025 16:24:05 GMT
Subject: RFR: 8370074: Remove unused code in AbstractDebuggeeTest.java
In-Reply-To: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
References: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
Message-ID: <XPoivZYTOelL2vMSbBoFnOpBTPz2DqJXpZu0l_e2VUA=.f964ac15-4ef1-4997-9961-56c62a65af4f@github.com>

On Fri, 17 Oct 2025 09:48:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Changes look good. Please make sure you run all of nsk/jdi, nsk/jdb, and nsk/jdwp. tier1 testing does not cover any of this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27863#pullrequestreview-3351038475

From fandreuzzi at openjdk.org  Fri Oct 17 16:25:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 16:25:47 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v11]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <i8iBQsurfocx4D3bD-oMCGP1d92Yo7S16s-9Xh5pfAE=.1339ab21-856d-43ba-bd68-10baa0b94f7d@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  msg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/1af09f8b..93667b80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=09-10

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

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

From fandreuzzi at openjdk.org  Fri Oct 17 17:53:28 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 17:53:28 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v12]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <eAzzuSxhvOcZwmxSbrvW9M1vrpMN26e152iq4oGWG_c=.ba73c2a3-5b12-4367-9dfa-a6d04f34e207@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  nullptr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/93667b80..2e628c60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=10-11

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

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

From kevinw at openjdk.org  Fri Oct 17 17:54:04 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 17 Oct 2025 17:54:04 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute
In-Reply-To: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
Message-ID: <tILHbBKfBq7m7aCbZFRBoj4KbREmXpFPtBEr3pkySfM=.9c1ff49f-ab3f-40bb-8710-b33f542038ec@github.com>

On Thu, 16 Oct 2025 13:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

I realise this works, I'm just thinking it's more about functions that end on a call, so the saved RIP is outside the function's range.
Seeing .cold is a hint that we should add 1 to apparent function length?
There are plenty of other functions that end in a call, and we would not report them correctly.

I wondered if all ".cold" functions have padding.
This common abort func does have the nop.
Scanning objdump -d libjvm.so I see there are quite a few  .cold functions that end in a call and a new func starts immediately after.
So we would report the wrong function in some cases.

They are quite obscure and not likely to happen.
e.g. we name _ZL21base_of_encoded_valuehP15_Unwind_Context.cold instead of _ZL28read_encoded_value_with_basehmPKhPm.cold

Maybe it's better we get the common case correct. 8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3416524462

From amenkov at openjdk.org  Fri Oct 17 19:03:07 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 17 Oct 2025 19:03:07 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v6]
In-Reply-To: <o0Naj-SeivOoSILJPzLYIyO0K7Pn_PLkVrw8GGCKROY=.ea810e9f-2f72-418c-ab2a-89fd364b7cfc@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <o0Naj-SeivOoSILJPzLYIyO0K7Pn_PLkVrw8GGCKROY=.ea810e9f-2f72-418c-ab2a-89fd364b7cfc@github.com>
Message-ID: <z9XVre44IqtGvSM02OjuaTpkg3p7fPoJ9h2wGG_cwDI=.7991eff2-b142-4c89-bbc2-c6564197cacf@github.com>

On Fri, 17 Oct 2025 02:29:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test might fail with 
>> 
>> ----------System.out:(5/399)----------
>> The following fake exception stacktrace is for failure analysis.
>> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> at nsk_lvcomplain(nsk_tools.cpp:172)
>> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
>> 
>> if some of threads unexpectedly finishes during test execution. 
>> 
>> 
>> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed threadList

There are still some wrong usage `thread_count` instead of `debuggee_threads_cnt`

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp line 165:

> 163:                 if (usageInfo.owner == nullptr)
> 164:                     break;
> 165:                 for (cThread = 0; cThread < threads_count; cThread++) {

Suggestion:

                for (cThread = 0; cThread < debuggee_threads_cnt; cThread++) {

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp line 175:

> 173:                     jvmti->Deallocate((unsigned char*)usageInfo.notify_waiters);
> 174:                 }
> 175:                 if (!NSK_VERIFY(cThread != threads_count))

Suggestion:

                if (!NSK_VERIFY(cThread != debuggee_threads_cnt))

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t001/tc03t001.cpp line 194:

> 192: 
> 193:     /* deallocate thread names */
> 194:     for (i = 0; i < threads_count; i++) {

Suggestion:

    for (i = 0; i < debuggee_threads_cnt; i++) {

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp line 166:

> 164:                 if (usageInfo.owner == nullptr)
> 165:                     break;
> 166:                 for (cThread = 0; cThread < threads_count; cThread++) {

Suggestion:

                for (cThread = 0; cThread < debuggee_threads_cnt; cThread++) {

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp line 176:

> 174:                     jvmti->Deallocate((unsigned char*)usageInfo.notify_waiters);
> 175:                 }
> 176:                 if (!NSK_VERIFY(cThread != threads_count))

Suggestion:

                if (!NSK_VERIFY(cThread != debuggee_threads_cnt))

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/tc03t002.cpp line 195:

> 193: 
> 194:     /* deallocate thread names */
> 195:     for (i = 0; i < threads_count; i++) {

Suggestion:

    for (i = 0; i < debuggee_threads_cnt; i++) {

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

Changes requested by amenkov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27831#pullrequestreview-3351575953
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2440938683
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2440940171
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2440941664
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2440946873
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2440947516
PR Review Comment: https://git.openjdk.org/jdk/pull/27831#discussion_r2440948100

From lmesnik at openjdk.org  Fri Oct 17 19:46:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 19:46:35 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v7]
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <fNbbgCMdt9pjsjGKhu4n1p7-ZpcWhmJwhiyVcWgsdZo=.f2e12e8d-0010-4089-9513-c4c9cfcca7bc@github.com>

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27831/files
  - new: https://git.openjdk.org/jdk/pull/27831/files/954fc280..507b7e18

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

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

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

From lmesnik at openjdk.org  Fri Oct 17 19:49:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 17 Oct 2025 19:49:02 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v6]
In-Reply-To: <z9XVre44IqtGvSM02OjuaTpkg3p7fPoJ9h2wGG_cwDI=.7991eff2-b142-4c89-bbc2-c6564197cacf@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <o0Naj-SeivOoSILJPzLYIyO0K7Pn_PLkVrw8GGCKROY=.ea810e9f-2f72-418c-ab2a-89fd364b7cfc@github.com>
 <z9XVre44IqtGvSM02OjuaTpkg3p7fPoJ9h2wGG_cwDI=.7991eff2-b142-4c89-bbc2-c6564197cacf@github.com>
Message-ID: <8aD4T1bXtAUBtFOKqXH2E4Y5HqVBP8EBy3nTFiMg-ms=.71d56c4b-b1e0-4a7f-a876-4a43baaf4b31@github.com>

On Fri, 17 Oct 2025 19:00:25 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> There are still some wrong usage `thread_count` instead of `debuggee_threads_cnt`
Thanks, I applied your changes and tested them.

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

PR Comment: https://git.openjdk.org/jdk/pull/27831#issuecomment-3416886152

From fandreuzzi at openjdk.org  Fri Oct 17 20:16:28 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 20:16:28 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  fix tool call

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/2e628c60..30b2cf96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=11-12

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

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

From sspitsyn at openjdk.org  Fri Oct 17 21:09:12 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 17 Oct 2025 21:09:12 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
Message-ID: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>

With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
The following API's are being added with this enhancement:

Introduce:
 - new capability: `can_get_gc_cpu_time`
 - new JVMTI functions:
    - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
    - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`

The related CSR will be created shortly.

Testing:
 - TBD: Mach5 tiers 1-6

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

Commit messages:
 - 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime

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

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

From amenkov at openjdk.org  Fri Oct 17 21:31:07 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 17 Oct 2025 21:31:07 GMT
Subject: RFR: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE [v7]
In-Reply-To: <fNbbgCMdt9pjsjGKhu4n1p7-ZpcWhmJwhiyVcWgsdZo=.f2e12e8d-0010-4089-9513-c4c9cfcca7bc@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
 <fNbbgCMdt9pjsjGKhu4n1p7-ZpcWhmJwhiyVcWgsdZo=.f2e12e8d-0010-4089-9513-c4c9cfcca7bc@github.com>
Message-ID: <Ujei0Gw0PLy_nIu4-lED0xirScP-4FQabjQfZZstBAw=.3037567d-dd40-490e-bbca-125b55ad066f@github.com>

On Fri, 17 Oct 2025 19:46:35 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Test might fail with 
>> 
>> ----------System.out:(5/399)----------
>> The following fake exception stacktrace is for failure analysis.
>> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> at nsk_lvcomplain(nsk_tools.cpp:172)
>> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
>> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
>> 
>> if some of threads unexpectedly finishes during test execution. 
>> 
>> 
>> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Alex Menkov <alexey.menkov at oracle.com>

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27831#pullrequestreview-3352153881

From duke at openjdk.org  Fri Oct 17 22:59:59 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 17 Oct 2025 22:59:59 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <wgstDmBJXAX42V6dyOZJPZiolxexEiBN15kCUQBZHaI=.7d991ed5-3d5d-42b6-bf1e-011587427b54@github.com>

On Fri, 17 Oct 2025 21:02:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> The related CSR will be created shortly.
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Thanks for making this happen! I think it looks good from my point of view, I have just one question, is it safe to skip the check for `os::is_thread_cpu_time_supported`? One might ask why `CPUTimeUsage` does not handle that, but since these methods are also used by internal GC functionality this was intentionally omitted for performance reasons (and some GCs like G1 won't run if thread CPU time is not supported so that call is not always needed). I'm no JVMTI expert so this might be fine, like how its fine for G1 to omit calling it, but just wanted to ask.

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

PR Review: https://git.openjdk.org/jdk/pull/27879#pullrequestreview-3352329567

From sspitsyn at openjdk.org  Sat Oct 18 00:45:01 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Oct 2025 00:45:01 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
In-Reply-To: <wgstDmBJXAX42V6dyOZJPZiolxexEiBN15kCUQBZHaI=.7d991ed5-3d5d-42b6-bf1e-011587427b54@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <wgstDmBJXAX42V6dyOZJPZiolxexEiBN15kCUQBZHaI=.7d991ed5-3d5d-42b6-bf1e-011587427b54@github.com>
Message-ID: <uCNoQo2-ywSpNobg7MoH-03SNdtmkJiTO9B6rBlMnJo=.128e47e3-c30f-488a-a8bb-2a0a17a8800e@github.com>

On Fri, 17 Oct 2025 22:57:43 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Thanks for making this happen! I think it looks good from my point of view, I have just one question, is it safe to skip the check for os::is_thread_cpu_time_supported? One might ask why CPUTimeUsage does not handle that, but since these methods are also used by internal GC functionality this was intentionally omitted for performance reasons (and some GCs like G1 won't run if thread CPU time is not supported so that call is not always needed). I'm no JVMTI expert so this might be fine, like how its fine for G1 to omit calling it, but just wanted to ask.

Thank you for looking at it and comment! Yes, I was thinking about this check but have not came to any conclusion yet. Yes, I was thinking if this check would be simpler to add to the `CPUTimeUsage` and understand your point about performance reasons. From the other hand it is possible for `CPUTimeUsage::GC::total()` to just always return `-1` if `!os::is_thread_cpu_time_supported()`. While it is better to have it implemented in some common place, I'm not very religious about it and could add it to the JVMTI functions. One problem with that is consistency. There is no such check in the existing JVMTI functions like `GetThreadCpuTime()`,  `GetCurrentThreadCpuTime()`, `GetThreadCpuTimerInfo()` and `GetCurrentThreadCpuTimerInfo()`.
However, I've just added this check to the `GetTotalGCCpuTime()`. Please, let me know your opinion.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3417637848

From sspitsyn at openjdk.org  Sat Oct 18 00:50:59 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Oct 2025 00:50:59 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v2]
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <Istcl5nUS9vt7Rt4aLgbYR-Hn1d8a2r9zlBpNtTYnXE=.a70cab83-4da3-4ffd-8141-65b27df137de@github.com>

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> The related CSR will be created shortly.
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  Review: add os::is_thread_cpu_time_supported() check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27879/files
  - new: https://git.openjdk.org/jdk/pull/27879/files/b3bc092f..1fef0d71

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

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

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

From lmesnik at openjdk.org  Sat Oct 18 00:53:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 18 Oct 2025 00:53:11 GMT
Subject: Integrated: 8321687: Test
 vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java
 failed: JVMTI_ERROR_THREAD_NOT_ALIVE
In-Reply-To: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
References: <ldhv5baCW9Ej5EdZX3fLpvZuksAxWqFyC6J1vUwyvTM=.ea8cd7ac-af8a-4fb8-b154-e65504ab2bb0@github.com>
Message-ID: <1UqOs5LBAAaSJaoHO5y1NMLDY-FxH9Ti6EJqOTItJ1c=.d696213f-b803-4961-9794-f50e33d1692c@github.com>

On Wed, 15 Oct 2025 20:38:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test might fail with 
> 
> ----------System.out:(5/399)----------
> The following fake exception stacktrace is for failure analysis.
> nsk.share.Fake_Exception_for_RULE_Creation: (tc03t002.cpp:144) jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> at nsk_lvcomplain(nsk_tools.cpp:172)
> # ERROR: tc03t002.cpp, 144: jvmti->GetCurrentContendedMonitor(threadList[pThread].thread, &monitor)
> # jvmti error: code=15, name=JVMTI_ERROR_THREAD_NOT_ALIVE
> 
> if some of threads unexpectedly finishes during test execution. 
> 
> 
> It might happens only for some tests that are not started and verified by thread. So the fix is to skip them and verify only "Debugee" threads that might be in the deadlock.

This pull request has now been integrated.

Changeset: 18165708
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/181657084a547457327b8657d7a8d3faa17eb1f5
Stats:     85 lines in 4 files changed: 28 ins; 0 del; 57 mod

8321687: Test vmTestbase/nsk/jvmti/scenarios/contention/TC03/tc03t002/TestDescription.java failed: JVMTI_ERROR_THREAD_NOT_ALIVE

Reviewed-by: amenkov, cjplummer, sspitsyn

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

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

From sspitsyn at openjdk.org  Sat Oct 18 00:56:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 18 Oct 2025 00:56:25 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> The related CSR will be created shortly.
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  fix a typo in GetGCCpuTimerInfo: long => jlong

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27879/files
  - new: https://git.openjdk.org/jdk/pull/27879/files/1fef0d71..d816a56d

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

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

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

From ayang at openjdk.org  Sat Oct 18 10:14:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 18 Oct 2025 10:14:03 GMT
Subject: RFR: 8370074: Remove unused code in AbstractDebuggeeTest.java
In-Reply-To: <XPoivZYTOelL2vMSbBoFnOpBTPz2DqJXpZu0l_e2VUA=.f964ac15-4ef1-4997-9961-56c62a65af4f@github.com>
References: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
 <XPoivZYTOelL2vMSbBoFnOpBTPz2DqJXpZu0l_e2VUA=.f964ac15-4ef1-4997-9961-56c62a65af4f@github.com>
Message-ID: <daM-uFJFmHh8zgTOaZhsg2E5fyWlEGioZ2e7Ewki-Dw=.009ea193-75bc-44b0-bb9b-e72a51d8f65d@github.com>

On Fri, 17 Oct 2025 16:21:25 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Please make sure you run all of nsk/jdi, nsk/jdb, and nsk/jdwp.

All `TEST=vmTestbase/` pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/27863#issuecomment-3418163007

From ysuenaga at openjdk.org  Sat Oct 18 12:37:01 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 18 Oct 2025 12:37:01 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute
In-Reply-To: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
Message-ID: <pPRJf1LHinj2GOE_e7nefyqCa_KYvUfWrvaxAUOB9FE=.b75d2402-55bb-4add-9356-05aaf3153170@github.com>

On Thu, 16 Oct 2025 13:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

I looked into the spec / implementation in GDB, binutils, GCC - but I could not find out unfortunately... It might be a convention that debugger like GDB can handle it correctly.

In GDB, we can see following frame information. `_ZN2os5abortEbPKvS1_.cold` (`os::abort(bool, void const*, void const*) [clone .cold]` in demangling) from jumped by ` _ZN2os5abortEbPKvS1_` (`os::abort(bool, void const*, void const*)`), thus they are same frame.


(gdb) disas
Dump of assembler code for function _ZN2os5abortEbPKvS1_:
Address range 0x7f3e1ef0f850 to 0x7f3e1ef0f888:
   0x00007f3e1ef0f850 <+0>:     push   %rbp
   0x00007f3e1ef0f851 <+1>:     mov    %rsp,%rbp
   0x00007f3e1ef0f854 <+4>:     push   %rbx
   0x00007f3e1ef0f855 <+5>:     mov    %edi,%ebx
   0x00007f3e1ef0f857 <+7>:     sub    $0x8,%rsp
   0x00007f3e1ef0f85b <+11>:    call   0x7f3e1ef0f820 <_ZN2os8shutdownEv>
   0x00007f3e1ef0f860 <+16>:    test   %bl,%bl
   0x00007f3e1ef0f862 <+18>:    jne    0x7f3e1ef0f86e <_ZN2os5abortEbPKvS1_+30>
   0x00007f3e1ef0f864 <+20>:    mov    $0x1,%edi
   0x00007f3e1ef0f869 <+25>:    call   0x7f3e1da01250 <_exit at plt>
   0x00007f3e1ef0f86e <+30>:    lea    0x1167254(%rip),%rax        # 0x7f3e20076ac9 <DumpPrivateMappingsInCore>
   0x00007f3e1ef0f875 <+37>:    cmpb   $0x0,(%rax)
   0x00007f3e1ef0f878 <+40>:    je     0x7f3e1da01f2e <_ZN2os5abortEbPKvS1_.cold>
   0x00007f3e1ef0f87e <+46>:    call   0x7f3e1e1d2010 <_ZN11ClassLoader15close_jrt_imageEv>
   0x00007f3e1ef0f883 <+51>:    jmp    0x7f3e1da01f2e <_ZN2os5abortEbPKvS1_.cold>
Address range 0x7f3e1da01f2e to 0x7f3e1da01f33:
   0x00007f3e1da01f2e <-22075682>:      call   0x7f3e1da01010 <abort at plt>
End of assembler dump.


The key point is that `RIP` does not point jump'ed code (in `.cold`). `RIP` points the next instruction. It is not covered in both symtab and DWARF.


(gdb) disas 0x7f3e1da01f2e,0x7f3e1da01f34
Dump of assembler code from 0x7f3e1da01f2e to 0x7f3e1da01f34:
   0x00007f3e1da01f2e <_ZN2os5abortEbPKvS1_.cold+0>:    call   0x7f3e1da01010 <abort at plt>
=> 0x00007f3e1da01f33:  nop
End of assembler dump.


My goal is to unwind all of call frames in `jhsdb jstack --mixed` without any unknown symbols.  To realize it, I think it is better to scan the address `RIP - 1` when SA cannot resolve symbol / find DWARF CFA as a fallback. I think it is reasonable than to make change in symtab.c like this PR. @kevinjwalls What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3418401185

From kbarrett at openjdk.org  Sat Oct 18 17:11:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 18 Oct 2025 17:11:48 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
Message-ID: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>

> Please review this change to the HotSpot Style Guide to suggest that C++
> Standard Library components may be used, after appropriate vetting and
> discussion, rather than just a blanket "no, don't use it" with a few very
> narrow exceptions. It provides some guidance on that vetting process and
> the criteria to use, along with usage patterns.
> 
> In particular, it proposes that Standard Library headers should not be
> included directly, but instead through HotSpot-provided wrapper headers. This
> gives us a place to document usage, provide workarounds for platform issues in
> a single place, and so on.
> 
> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
> `<type_traits>`, along with updates to use them. I have a separate change for
> `<new>` that I plan to propose later, under JDK-8369187. There will be
> additional followups for other C compatibility headers besides `<cstddef>`.
> 
> This PR also cleans up some nomenclature issues around forbid vs exclude and
> the like.
> 
> Testing: mach5 tier1-5, GHA sanity tests

Kim Barrett 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 stdlib-header-wrappers
 - Merge branch 'master' into stdlib-header-wrappers
 - Merge branch 'master' into stdlib-header-wrappers
 - jrose comments
 - move tuple to undecided category
 - add wrapper for <type_traits>
 - add wrapper for <cstddef>
 - add wrapper for <limits>
 - style guide permits some standard library facilities

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

Changes: https://git.openjdk.org/jdk/pull/27601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27601&range=03
  Stats: 670 lines in 68 files changed: 430 ins; 134 del; 106 mod
  Patch: https://git.openjdk.org/jdk/pull/27601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27601/head:pull/27601

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

From lmesnik at openjdk.org  Sat Oct 18 17:14:35 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 18 Oct 2025 17:14:35 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
Message-ID: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>

The problem happens when jni access fields while the last java frame is still compiled. The field access/modification events require interp only mode and compiled frame is not expected. However,  It might happens if thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 

The original example doesn't reproduce issue because of JDK changes but the problem exists in JVMTI. So I implemented reliable regression test. 

The location should be zero for JNI access.

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

Commit messages:
 - the new test added
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8224852
 - logging fixed
 - minor fixes
 - 8224852: JVM crash on watched field access from native code

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

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

From lmesnik at openjdk.org  Sat Oct 18 17:24:43 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 18 Oct 2025 17:24:43 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v2]
In-Reply-To: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
Message-ID: <jLcTWqm4cz7c863ysJVqjbdiaQlERnpJZHHB3F4AECo=.04631781-37ff-49d8-a206-78b4c15a414a@github.com>

> The problem happens when jni access fields while the last java frame is still compiled. The field access/modification events require interp only mode and compiled frame is not expected. However,  It might happens if thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
> 
> The original example doesn't reproduce issue because of JDK changes but the problem exists in JVMTI. So I implemented reliable regression test. 
> 
> The location should be zero for JNI access.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27584/files
  - new: https://git.openjdk.org/jdk/pull/27584/files/8b18b5bb..bb5837ec

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

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

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

From lmesnik at openjdk.org  Sat Oct 18 17:25:09 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 18 Oct 2025 17:25:09 GMT
Subject: RFR: 8370074: Remove unused code in AbstractDebuggeeTest.java
In-Reply-To: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
References: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
Message-ID: <1mfx42JcGvPj9iv5fn4QGS6sgxWsSnHjVnzxYaAShu0=.5132c15b-9bc5-47d7-8abb-4ddd98bd1d1e@github.com>

On Fri, 17 Oct 2025 09:48:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1 and `TEST=vmTestbase/`

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27863#pullrequestreview-3353667755

From ysuenaga at openjdk.org  Sun Oct 19 07:03:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 19 Oct 2025 07:03:42 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack with
 -Xcomp
Message-ID: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>

`jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.

It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.


----------------- 646689 -----------------
"Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   JavaThread state: _thread_blocked
0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
0x00007f1cf218789f JVM_SleepNanos + 0x28f
0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)


`Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.


----------------- 646841 -----------------
"Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
   JavaThread state: _thread_blocked
0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
0x00007f4a0918789f JVM_SleepNanos + 0x28f
0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
                        * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
0x00007f49ef3385fd <StubRoutines (initial stubs)>
0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
0x00007f4a08fc31bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
0x00007f4a09185590 thread_entry(JavaThread*, JavaThread*) + 0xd0
0x00007f4a09004206 JavaThread::thread_main_inner() + 0x256
0x00007f4a09c66747 Thread::call_run() + 0xb7
0x00007f4a096fccc8 thread_native_entry(Thread*) + 0x128
0x00007f4a0aa20f54 start_thread + 0x2e4


Java frame might be use the register for frame pointer (`RBP` in AMD64) as general purpose register, so SA cannot rely it in stack unwinding.

hs_err log has mixed stack trace as "Native frames", it would be unwinded by `NativeStackPrinter` in HotSpot, and it works as mixed mode. `NativeStackPrinter` uses `frame::next_frame()` to find sender frame regardless whether Java frame or C frame, and it leverages sender FP/PC to create sender frame. On the other hand, SA separates CFrame and VFrame to unwind in mixed mode jstack, so sender FP/PC would not propagate to CFrame, thus the frame located at bottom of Java frame might not be shown.

It is difficult to unify unwinder in `PStack` in SA, so it would be reasonable to propagate sender FP/PC to the sender of CFrame.

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

Commit messages:
 - Update bug ID in testcase
 - Add change for AArch64
 - Mixed jstack does not work without -XX:+PreserveFramePointer

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

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

From alanb at openjdk.org  Sun Oct 19 10:25:01 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Oct 2025 10:25:01 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> There is also interest to get the same performance data from JVMTI.

Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).

As a general point, the JVMTI spec doesn't have much support for monitoring GC. It has GC start/end events that date from the original spec when collectors were all STW and it hasn't evolved since to model more modern collectors.

I'm sure CPU time spend on GC is important to many profilers but I'm also wondering if JVMTI is the right API for modern profilers to be using. JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.

(n passing, I see GetAvailableProcessors is in the Timers section of the spec, is that the right place for this?)

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419554152

From duke at openjdk.org  Sun Oct 19 15:40:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 15:40:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
Message-ID: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>

On Sun, 19 Oct 2025 10:21:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).

Certainly, thanks for asking. Researchers in GC are using the GC start/end events (https://dl.acm.org/doi/10.1145/3669940.3707217, https://ieeexplore.ieee.org/document/9804613, https://dl.acm.org/doi/10.1145/3764118, https://dl.acm.org/doi/10.1145/3652024.3665510 etc.) to understand various costs pertaining to GC. I believe one USP of using a JVMTI agent is that it does not require modification of the benchmarking code and allows usage of powerful features made available by framework such as libpfm. 

So these JVMTI hooks are used to read CPU performance counters to get some estimations of various metrics, be it CPU time, cache-misses etc. However this imposes severe limitations especially when it comes GCs with concurrent parts. This patch will expand the capabilities for these users using JVMTI agents to profile applications.

> there aren't functions to get the process CPU time for example

I think there is no need for JVMTI to export such functionality as it should be trivial for a C/C++ application to get process CPU time through other means. However getting GC CPU time (outside the scope of stop-the-world) would be less trivial without this patch.

> JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.

I believe JVMTI is still relevant for profiling as it is being used in the GC research community.

On a general note, I think exposing GC CPU time at various APIs will serve a different scope of users. At this level we support users that uses advanced profiling techniques with external libraries.

Hope this helps.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419754679

From duke at openjdk.org  Sun Oct 19 16:42:10 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 16:42:10 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <fx6TruXKrfRpA7RMm5GsC8WIpScaVr8201MK8i1hnmI=.5d145adb-8fa3-4b8f-8e94-b29608415791@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

src/hotspot/share/prims/jvmtiH.xsl line 120:

> 118:     JVMTI_VERSION_19  = 0x30130000,
> 119:     JVMTI_VERSION_21  = 0x30150000,
> 120:     JVMTI_VERSION_25  = 0x30170000,

Should this be `JVMTI_VERSION_26` if this is targeted for version 26?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443390372

From duke at openjdk.org  Sun Oct 19 17:06:06 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 17:06:06 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <GaCutHRWuK72QjyBX-RPYIqjZycVAHURB5vd6HDuNWo=.d2b9dc5d-69f7-4c7a-bd4c-dd5e63489caa@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

src/hotspot/share/prims/jvmtiManageCapabilities.cpp line 95:

> 93:     jc.can_get_current_thread_cpu_time = 1;
> 94:     jc.can_get_thread_cpu_time = 1;
> 95:     jc.can_get_gc_cpu_time = 1;

I'm wondering, would a user trying to call `GetTotalGCCpuTime` if `can_get_gc_cpu_time` is not successfully set to 1 be undefined behavior? The specs say "To possess a capability, the agent must add the capability (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#capability). If yes maybe we can discard the extra call to `os::is_thread_cpu_time_supported` in `JvmtiEnv::GetTotalGCCpuTime`? That seems to align with the pattern to not have that check in the other methods as you pointed out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443399514

From duke at openjdk.org  Sun Oct 19 17:46:10 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 17:46:10 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <Q4FpxJ60YhHKrh2fd-nbaae6c8EwyC-vZI7FDK7TI0M=.ca2ccca3-0d25-4bfc-8835-16fd466906b5@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

src/hotspot/share/prims/jvmti.xml line 11234:

> 11232:     </function>
> 11233: 
> 11234:     <function id="GetGCCpuTimerInfo" phase="any" callbacksafe="safe" num="157" since="26">

Should this be called `GetTotalGCCpuTimerInfo`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443414405

From duke at openjdk.org  Sun Oct 19 18:45:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 19 Oct 2025 18:45:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

There may be two issues with the patch as is:

Calling `GetTotalGCCpuTime` in `Agent_OnLoad` can cause crash (since `CollectedHeap::gc_threads_do` do not protect against races on VM startup/shutdown).

If `GetTotalGCCpuTime` is invoked in a callback for GC start/end, this will cause a deadlock as the `Heap_lock` is already held. The `MutexLocker hl(Heap_lock)` pattern was introduced to avoid races that could happen from internal usage in G1 of `CPUTimeUsage::GC::total()` during shutdown. I could recall this wrong but I think the usage `Heap_lock` (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of `Universe::_is_shutting_down`. I will ask @walulyai for his thoughts.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3419871071

From kevinw at openjdk.org  Sun Oct 19 20:05:01 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Sun, 19 Oct 2025 20:05:01 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute
In-Reply-To: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
Message-ID: <eRONGlRRFvm2ABsuvNDHaDgYaBeU8HojiH0y6i2j_Bo=.3a571c64-0517-4d87-8ba6-dfaeda4a28f4@github.com>

On Thu, 16 Oct 2025 13:32:28 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

Are you thinking of doing a second pass: if symbol not found, look again using RIP-1. That should work for this case. 
(Or on the second pass, use the one byte longer object/function length.)

It won't be perfect but I'm not sure what will be without getting quite context sensitive.  Even recognising that we are looking one byte past the end of a function, and that the  instruction immediately lower in memory was a call, would need checking whether the called frame is that call, or if we just jumped to a function that starts in memory immediately after a funtion that ends in a call.

I think we should be OK with something that works for most cases, and works better than today, and maybe the second pass does that.  8-)

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3419917455

From ysuenaga at openjdk.org  Mon Oct 20 01:23:45 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 20 Oct 2025 01:23:45 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute [v2]
In-Reply-To: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
Message-ID: <ELbHByCRzbYuT-h_4DI2aT6byRpWAeHjAV97Jj_73uo=.03889f05-5b7e-45dd-a6c0-cac6011c4807@github.com>

> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735 __GI_abort + 0x8b
> 0x00007f50e1e01f33 ????????
> 
> 
> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
> 
> 
> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
> => 0x00007f50e1e01f33: nop
> End of assembler dump.
> 
> 
> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
> 
> After this PR, you can see the right symbol as following:
> 
> 
> ----------------- 120485 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f50e4710735      __GI_abort + 0x8b
> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5

Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:

 - Add fallback code to process DWARF with RIP-1 in Linux AMD64
 - Revert "8369994: Mixed mode jhsdb jstack cannot resolve symbol with cold attribute"
   
   This reverts commit 570b65c6b56ba3378d4f532fa0874ff08ff18451.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27846/files
  - new: https://git.openjdk.org/jdk/pull/27846/files/570b65c6..3492a833

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

  Stats: 56 lines in 2 files changed: 26 ins; 15 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/27846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27846/head:pull/27846

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

From ysuenaga at openjdk.org  Mon Oct 20 01:23:46 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 20 Oct 2025 01:23:46 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute
In-Reply-To: <eRONGlRRFvm2ABsuvNDHaDgYaBeU8HojiH0y6i2j_Bo=.3a571c64-0517-4d87-8ba6-dfaeda4a28f4@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
 <eRONGlRRFvm2ABsuvNDHaDgYaBeU8HojiH0y6i2j_Bo=.3a571c64-0517-4d87-8ba6-dfaeda4a28f4@github.com>
Message-ID: <BSTZpBTAS3VqnTOdt1-XpkDWqPgdropDjZRgugk6kKI=.d4295491-981d-4afd-98f7-7c1a3717690b@github.com>

On Sun, 19 Oct 2025 20:02:32 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735 __GI_abort + 0x8b
>> 0x00007f50e1e01f33 ????????
>> 
>> 
>> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
>> 
>> 
>> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
>> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
>> => 0x00007f50e1e01f33: nop
>> End of assembler dump.
>> 
>> 
>> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
>> 
>> After this PR, you can see the right symbol as following:
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735      __GI_abort + 0x8b
>> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5
>
> Are you thinking of doing a second pass: if symbol not found, look again using RIP-1. That should work for this case. 
> (Or on the second pass, use the one byte longer object/function length.)
> 
> It won't be perfect but I'm not sure what will be without getting quite context sensitive.  Even recognising that we are looking one byte past the end of a function, and that the  instruction immediately lower in memory was a call, would need checking whether the called frame is that call, or if we just jumped to a function that starts in memory immediately after a funtion that ends in a call.
> 
> I think we should be OK with something that works for most cases, and works better than today, and maybe the second pass does that.  8-)

@kevinjwalls Thanks a lot for your comment! I added second pass with `RIP-1` if DWARF would not be processed with given `RIP`. All of hotspot_serviceability tests have been passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3420191937

From syan at openjdk.org  Mon Oct 20 02:12:17 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 20 Oct 2025 02:12:17 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount [v2]
In-Reply-To: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
References: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
Message-ID: <KxKUm0pkHuDIwS1g6oT956dX6Pjbd3_vzFSNeVFzVI0=.ee630699-f8dd-46bc-ab90-710ac15221cf@github.com>

> Hi all,
> 
> The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.
> 
> Change has been verified locally on linux-x64. Test fix only, no risk.
> 
> 
>> free -h
> total used free shared buff/cache available
> Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
> Swap: 0B 0B 0B
> 
> 
> Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
> OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)
> 
> 
> With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
> 137

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

  Update the comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27823/files
  - new: https://git.openjdk.org/jdk/pull/27823/files/8d6a2b17..20ed6df6

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

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

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

From syan at openjdk.org  Mon Oct 20 02:12:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 20 Oct 2025 02:12:19 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount [v2]
In-Reply-To: <f9vQI006FNcPw81wUBCyR5qDOQBmU8NHvQ7R3f2YZMI=.5eea614a-64a6-409a-8169-8c235857d913@github.com>
References: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
 <f9vQI006FNcPw81wUBCyR5qDOQBmU8NHvQ7R3f2YZMI=.5eea614a-64a6-409a-8169-8c235857d913@github.com>
Message-ID: <b4kkIUNZLwmln0RdBQJU-SqjmUscry3e6DcQaeZQhrc=.08ad5cd8-f861-41dd-bdd2-18ebef5cbae5@github.com>

On Thu, 16 Oct 2025 15:28:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please amend the comment on line 114 to something like this:
> 
> ```
>         // Check whether swapping really works for this test
>         // On some systems there is no swap space enabled. And running
>         // 'java -Xms{mem-limit} -Xmx{mem-limit} -XX:+AlwaysPreTouch -version'
>         // would fail due to swap space size being 0. Note that when swap is
>         // properly enabled on the system the container gets the same amount
>         // of swap as is configured for memory. Thus, 2x{mem-limit} is the actual
>         // memory and swap bound for this pre-test.
> ```

Thanks for the suggestions. The Comment has been updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/27823#issuecomment-3420271458

From dholmes at openjdk.org  Mon Oct 20 04:48:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Oct 2025 04:48:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <M2u2LiPE7eCtO2uxXoHlB6fZ0BS3FYWGf4DHi0-XqAg=.93fc881a-5e46-474c-9abe-3316966ad71c@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

I have a few issues with the spec and implementation, but they are easily addressed.

I'm not sure this functionality is really JVMTI worthy but if Jonas thinks this is useful for GC profiling then I will take hs word for it.

src/hotspot/share/prims/jvmti.xml line 11288:

> 11286:             On return, points to the time in nanoseconds.
> 11287:             This is an unsigned value.  If tested or printed as a jlong (signed value)
> 11288:             it may appear to be a negative number.

This seems to contradict the description that it could be relative to a value in the future and hence negative - thus it can't be "unsigned". But then I don't see how it can be as described - for this timer to be useful it must be tracking nanoseconds of CPU time consumed by GC since CPU time tracking commenced, sometime after VM startup. This has to be similar to how thread CPU time is defined.

src/hotspot/share/prims/jvmtiEnv.cpp line 3802:

> 3800:   {
> 3801:     MutexLocker hl(Heap_lock);
> 3802:     if (!os::is_thread_cpu_time_supported() ||

If it isn't supported then you can't have the capability and so won't reach here.

src/hotspot/share/prims/jvmtiEnv.cpp line 3804:

> 3802:     if (!os::is_thread_cpu_time_supported() ||
> 3803:         Universe::heap()->is_shutting_down()) {
> 3804:       *nanos_ptr = -1;

This seems wrong to me and violates the timer-info spec of this timer not jumping backwards. I think you have to cache the last returned value for this function and if you cannot calculate an updated value because of VM shutdown, then that previous value should be returned.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27879#pullrequestreview-3354987972
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443784044
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443799741
PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443800932

From dholmes at openjdk.org  Mon Oct 20 04:48:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 20 Oct 2025 04:48:06 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <fx6TruXKrfRpA7RMm5GsC8WIpScaVr8201MK8i1hnmI=.5d145adb-8fa3-4b8f-8e94-b29608415791@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <fx6TruXKrfRpA7RMm5GsC8WIpScaVr8201MK8i1hnmI=.5d145adb-8fa3-4b8f-8e94-b29608415791@github.com>
Message-ID: <bicbqp9p2-oF7cYx-bqPivKSuffHoLukGKT-AjVu-B4=.0fbba7bb-fd01-4863-a72f-3762cfe23ace@github.com>

On Sun, 19 Oct 2025 16:39:34 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix a typo in GetGCCpuTimerInfo: long => jlong
>
> src/hotspot/share/prims/jvmtiH.xsl line 120:
> 
>> 118:     JVMTI_VERSION_19  = 0x30130000,
>> 119:     JVMTI_VERSION_21  = 0x30150000,
>> 120:     JVMTI_VERSION_25  = 0x30170000,
> 
> Should this be `JVMTI_VERSION_26` if this is targeted for version 26?

Also the hex value represents JDK 23 not 25.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27879#discussion_r2443789919

From sgehwolf at openjdk.org  Mon Oct 20 06:25:03 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 20 Oct 2025 06:25:03 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount [v2]
In-Reply-To: <KxKUm0pkHuDIwS1g6oT956dX6Pjbd3_vzFSNeVFzVI0=.ee630699-f8dd-46bc-ab90-710ac15221cf@github.com>
References: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
 <KxKUm0pkHuDIwS1g6oT956dX6Pjbd3_vzFSNeVFzVI0=.ee630699-f8dd-46bc-ab90-710ac15221cf@github.com>
Message-ID: <ijxGljG3LTo0AyrJX59QSfERZaIbUB59ltVEyUvKhwA=.ec9fd772-8711-42df-859f-9b67a45032d3@github.com>

On Mon, 20 Oct 2025 02:12:17 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.
>> 
>> Change has been verified locally on linux-x64. Test fix only, no risk.
>> 
>> 
>>> free -h
>> total used free shared buff/cache available
>> Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
>> Swap: 0B 0B 0B
>> 
>> 
>> Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:
>> 
>>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
>> OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)
>> 
>> 
>> With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):
>> 
>>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
>> 137
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the comments

Looks OK to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27823#pullrequestreview-3355132735

From ysuenaga at openjdk.org  Mon Oct 20 06:59:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 20 Oct 2025 06:59:42 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
Message-ID: <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>

> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
> 
> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
> 
> 
> ----------------- 646689 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 
> 
> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
> 
> 
> ----------------- 646841 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
> 0x00007f4a08fc31bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
> 0x00007f4a091...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Update testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27885/files
  - new: https://git.openjdk.org/jdk/pull/27885/files/9d023257..a75aa29d

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

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

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

From syan at openjdk.org  Mon Oct 20 07:19:13 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 20 Oct 2025 07:19:13 GMT
Subject: RFR: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount [v2]
In-Reply-To: <ijxGljG3LTo0AyrJX59QSfERZaIbUB59ltVEyUvKhwA=.ec9fd772-8711-42df-859f-9b67a45032d3@github.com>
References: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
 <KxKUm0pkHuDIwS1g6oT956dX6Pjbd3_vzFSNeVFzVI0=.ee630699-f8dd-46bc-ab90-710ac15221cf@github.com>
 <ijxGljG3LTo0AyrJX59QSfERZaIbUB59ltVEyUvKhwA=.ec9fd772-8711-42df-859f-9b67a45032d3@github.com>
Message-ID: <ebJ8W_i0gq9J8Y1su6ZKOpfhHNfZPpE_mDdFhEGrGcE=.2fcd4a86-0894-4044-9331-01e212304f0c@github.com>

On Mon, 20 Oct 2025 06:22:26 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the comments
>
> Looks OK to me.

Thanks for the suggestions and reviews @jerboaa.

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

PR Comment: https://git.openjdk.org/jdk/pull/27823#issuecomment-3420869716

From syan at openjdk.org  Mon Oct 20 07:19:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Mon, 20 Oct 2025 07:19:14 GMT
Subject: Integrated: 8343340: Swapping checking do not work for
 MetricsMemoryTester failcount
In-Reply-To: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
References: <m-jrclVoOqO0ev7lBiBmCDR3VFQ40k5vYZLesk8MBaw=.5b7c08a0-e19c-4240-9659-e1aee472a7b7@github.com>
Message-ID: <NbZtBk8NHm6H4WfbZVn-bxNlNdqsHoIRudm53pi-MiE=.8bae6c54-d730-4e5a-b7cb-2ef2ddae0f8a@github.com>

On Wed, 15 Oct 2025 14:18:41 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> The sub-test failcount in jdk/internal/platform/docker/TestDockerMemoryMetrics.java requires swap memory enable on the test host. But the swap memory check introduced by JDK-8264524 do not work correctly, because it's missing jvm option '-XX:+AlwaysPreTouch', shows as below. This PR add jvm option '-XX:+AlwaysPreTouch' to make the swap memory check work correctly, and use jtreg.SkippedException instead of print waring when this test can not execute.
> 
> Change has been verified locally on linux-x64. Test fix only, no risk.
> 
> 
>> free -h
> total used free shared buff/cache available
> Mem: 751Gi 513Gi 229Gi 5.0Mi 8.4Gi 234Gi
> Swap: 0B 0B 0B
> 
> 
> Without jvm option -XX:+AlwaysPreTouch, the 'java -Xms128m -Xmx128m -version' can start successfully:
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -Xms128m -Xmx128m -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment HJDK-0 (build 26+-42b2999c)
> OpenJDK 64-Bit Server VM HJDK-0 (build 26+-42b2999c, mixed mode, sharing)
> 
> 
> With jvm option -XX:+AlwaysPreTouch, the 'java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version' can not start and killed by docker(return code is 137):
> 
>> docker run --rm --memory=128m jdk-internal:test-jdk-internal-platform-docker-TestDockerMemoryMetrics-metrics-memory /jdk/bin/java -XX:+AlwaysPreTouch -Xms128m -Xmx128m -version ; echo $?
> 137

This pull request has now been integrated.

Changeset: 7e068cc8
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7e068cc8d572e61cf2f4203f66fe0175a541209d
Stats:     14 lines in 2 files changed: 6 ins; 2 del; 6 mod

8343340: Swapping checking do not work for MetricsMemoryTester failcount

Reviewed-by: sgehwolf

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

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

From lkorinth at openjdk.org  Mon Oct 20 09:18:08 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 20 Oct 2025 09:18:08 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <ol4S2Q_rbwLwGQeZEYH4al1MFGB2-KrFSfLAaP4y16M=.3b95fd2f-a598-4842-9afc-b961d496fb56@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett 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 stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

I think this is a nice way forward. I would have liked more of the c++ library included (like tuples, optional and expected), but this is a good start.

Thanks for putting so much effort into this!!!

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

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3355641379

From ayang at openjdk.org  Mon Oct 20 09:23:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Oct 2025 09:23:16 GMT
Subject: RFR: 8370074: Remove unused code in AbstractDebuggeeTest.java
In-Reply-To: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
References: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
Message-ID: <XW7bbefIt6PuzNxeUs-nfcyJE97iKp6we8bwkiquaG4=.bda349ee-dcf0-43d2-8e44-5a8d6a942f1b@github.com>

On Fri, 17 Oct 2025 09:48:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1 and `TEST=vmTestbase/`

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27863#issuecomment-3421188699

From ayang at openjdk.org  Mon Oct 20 09:23:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Oct 2025 09:23:17 GMT
Subject: Integrated: 8370074: Remove unused code in AbstractDebuggeeTest.java
In-Reply-To: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
References: <9vj-1hXk4_F0GHh6svjuYv_S_mKbKP1tJjIddtJT4gI=.daed844a-4768-4049-86f9-d0c8019acc66@github.com>
Message-ID: <1-JlStOSZcLg5v66AcWRE-t18Za6mqdYKmw0vBKE6AE=.25ad4ae4-4dd1-48b1-bbae-fa22c92b1ff7@github.com>

On Fri, 17 Oct 2025 09:48:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1 and `TEST=vmTestbase/`

This pull request has now been integrated.

Changeset: 8c775e29
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c775e299dbf651c3be1ba84b9e50356a3503861
Stats:     10 lines in 1 file changed: 0 ins; 10 del; 0 mod

8370074: Remove unused code in AbstractDebuggeeTest.java

Reviewed-by: fandreuzzi, cjplummer, lmesnik

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

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

From adinn at openjdk.org  Mon Oct 20 09:27:16 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 20 Oct 2025 09:27:16 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
Message-ID: <FYcC9eKk5aGJH74Vbv6X9QKyMbpsDID6gWi_RlwMZKg=.a5f2140e-ada0-4dbf-918f-dff1721693e6@github.com>

On Wed, 15 Oct 2025 14:00:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge from the main branch
>>  - Address review comments
>>  - Address review comments
>>  - Address review comments
>>  - The patch is contributed by @TheRealMDoerr
>>  - Offset the deoptimization handler entry point
>>    
>>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>>  - Revert "Ensure stub code is not adjacent to a call"
>>  - Ensure stub code is not adjacent to a call
>>  - Address review comments
>>  - 8365047: Remove exception handler stub code in C2
>>    
>>    The C2 exception handler stub code is only a trampoline to the
>>    generated exception handler blob. This change removes the extra
>>    step on the way to the generated blob.
>>    
>>    According to some comments in the source code, the exception handler
>>    stub code used to be patched upon deoptimization, however presumably
>>    these comments are outdated as the patching upon deoptimization happens
>>    for post-call NOPs only.
>
> One probably related issue on linuxaarch64 while testing "gc/epsilon/TestObjects.java":
> SIGSEGV in caller_is_deopted:
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x5531b8]  caller_is_deopted(JavaThread*)+0x2f8  (nativeInst_aarch64.hpp:536)
> V  [libjvm.so+0x555000]  Runtime1::move_mirror_patching(JavaThread*)+0x20  (c1_Runtime1.cpp:1400)
> v  ~RuntimeStub::C1 Runtime load_mirror_patching_blob 0x0000f7cf038f316c
> 
> 
> 
> siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000f7cf03c60000
> 
> 
> That address is at the end of the stub section:
> 
> 
> R0 =0x00000000f001cee8 is an oop: java.util.HashMap 
> {0x00000000f001cee8} - klass: 'java/util/HashMap' - flags: is_cloneable_fast 
>  - ---- fields (total size 5 words):
>  - transient 'keySet' 'Ljava/util/Set;' @8  null (0x00000000)
>  - transient 'values' 'Ljava/util/Collection;' @12  null (0x00000000)
>  - transient 'table' '[Ljava/util/HashMap$Node;' @16  a 'java/util/HashMap$Node'[128] {0x00000000f001cf10} (0xf001cf10)
>  - transient 'entrySet' 'Ljava/util/Set;' @20  null (0x00000000)
>  - transient 'size' 'I' @24  60 (0x0000003c)
>  - transient 'modCount' 'I' @28  60 (0x0000003c)
>  - 'threshold' 'I' @32  96 (0x00000060)
>  - final 'loadFactor' 'F' @36  0.750000 (0x3f400000)
> R1 =0x0000001fd503201f is an unknown value
> R2 =0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
> Compiled method (c1) 5966 2946       1       java.util.HashMap::values (25 bytes)
>  total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
>  main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
>  stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
>  mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
>  relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
>  metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
>  immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
>  dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
>  scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
>  scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
>  speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
> 0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
> --------------------------------------------------------------------------------
>   0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
>   0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
> --------------------------------------------------------------------------------
> R3 =0x0000f7cf03817578 points into unknown readable ...

@TheRealMDoerr

I tried reproducing this on linuxaarch64 using my M2 Mac Studio/fedora and could not get it to reproduce with either DEBUG or RELEASE build.

There is something rather weird going here. The code at the offending address looks like this:

    0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
    0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
    0x0000f7cf03c60000:   <off the end of the nmethod>

That definitely looks like it is the new backward branch code for the deopt stub leading up to the nmethod tail. However, the generator code for the stub in c1_LIRAssembler is this:

    __ bind(start);
    __ far_jump(RuntimeAddress(SharedRuntime::deopt_blob()->unpack()));
    int entry_offset = __ offset();
    __ b(start);

Method `far_call` should have planted a `bkr` or `bl` not a `b`:

    void MacroAssembler::far_call(Address entry, Register tmp) {
      ...
      if (target_needs_far_branch(entry.target())) {
        uint64_t offset;
        // We can use ADRP here because we know that the total size of
        // the code cache cannot exceed 2Gb (ADRP limit is 4GB).
        adrp(tmp, entry, offset);
        add(tmp, tmp, offset);
        blr(tmp);
      } else {
        bl(entry);
      }

So, I don't understand how your test ended up with these two successive `b` instructions in the nmethod stub.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3421206833

From coffeys at openjdk.org  Mon Oct 20 09:50:14 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 20 Oct 2025 09:50:14 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3]
In-Reply-To: <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>
Message-ID: <G4Zyb6D8sUBMgsUqTIRGx2u37GDUpYurPe1dt6e2DVk=.d74d5347-74d6-4434-a69b-976fa167af78@github.com>

On Fri, 17 Oct 2025 11:11:19 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to jcmd Thread.print help message
>> 
>> jdk_svc test group ran and green
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further help message tweaks

Thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27861#issuecomment-3421292699

From coffeys at openjdk.org  Mon Oct 20 09:50:16 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 20 Oct 2025 09:50:16 GMT
Subject: Integrated: 8370071: Clarify jcmd Thread.print help message
In-Reply-To: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
Message-ID: <wA1BU8DXK-m20IdkEY_nFQP_MF4fayOKKGiw0HapDjs=.0d97b437-97be-4c21-973d-f94808d3a36b@github.com>

On Fri, 17 Oct 2025 08:50:45 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> Simple tweak to jcmd Thread.print help message
> 
> jdk_svc test group ran and green

This pull request has now been integrated.

Changeset: ee353201
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee353201d1c3f7521825ea852e37400277101164
Stats:     9 lines in 2 files changed: 4 ins; 0 del; 5 mod

8370071: Clarify jcmd Thread.print help message

Reviewed-by: kevinw

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

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

From adinn at openjdk.org  Mon Oct 20 09:53:14 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 20 Oct 2025 09:53:14 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <ZCnSDCLyDNKZvyijs3s0D7YGOyqoDSVJwFyTK1_0b3o=.3afa1882-1493-4934-8989-1b865047975c@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

Doh! Looking at the code properly this time it actually calls `far_jump` but, of course it should really be `far_call` (the C2 version was changed correctly). I believe that's the cause of the error (although it doesn't explain why the value in `lr` was the address after the nmethod tail).

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3421306619

From alanb at openjdk.org  Mon Oct 20 10:06:22 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Oct 2025 10:06:22 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3]
In-Reply-To: <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>
Message-ID: <SlMak729mZwqF-TPz1bu3cxnKY4JS61tKtuoNEFu7Lg=.c3faed6c-a965-400b-ac23-0fb1dc1cbd65@github.com>

On Fri, 17 Oct 2025 11:11:19 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Simple tweak to jcmd Thread.print help message
>> 
>> jdk_svc test group ran and green
>
> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further help message tweaks

src/hotspot/share/services/diagnosticCommand.hpp line 361:

> 359:     return "Print all platform threads, and mounted virtual threads, "
> 360:            "with stack traces. The Thread.dump_to_file command will "
> 361:            "print all threads to a file.";

I'm still in two minds about having it mention Thread.dump_to_file. If it is mentioned then it would be better to put in a line break and use "may be used to" that rather than "will".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2444514929

From iwalulya at openjdk.org  Mon Oct 20 10:29:04 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 20 Oct 2025 10:29:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
Message-ID: <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>

On Sun, 19 Oct 2025 18:41:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> There may be two issues with the patch as is:
> 
> Calling `GetTotalGCCpuTime` in `Agent_OnLoad` can cause crash (since `CollectedHeap::gc_threads_do` do not protect against races on VM startup/shutdown).
> 
> If `GetTotalGCCpuTime` is invoked in a callback for GC start/end, this will cause a deadlock as the `Heap_lock` is already held. The `MutexLocker hl(Heap_lock)` pattern was introduced to avoid races that could happen from internal usage in G1 of `CPUTimeUsage::GC::total()` during shutdown. I could recall this wrong but I think the usage `Heap_lock` (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of `Universe::_is_shutting_down`. I will ask @walulyai for his thoughts.

Right, there will be a deadlock if `GetTotalGCCpuTime` is called in the callbacks for events `GarbageCollectionStart`, `GarbageCollectionFinish`

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3421476400

From coffeys at openjdk.org  Mon Oct 20 11:26:43 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 20 Oct 2025 11:26:43 GMT
Subject: RFR: 8370071: Clarify jcmd Thread.print help message [v3]
In-Reply-To: <SlMak729mZwqF-TPz1bu3cxnKY4JS61tKtuoNEFu7Lg=.c3faed6c-a965-400b-ac23-0fb1dc1cbd65@github.com>
References: <VjC80_IOnurtdRnrd9Y8N0rfu-jKXJu_uvHiaGd2_Hc=.0a5187ba-74b6-4912-8c85-9287df0cf3f7@github.com>
 <PRI4t1l4c-cc3AuPiS8yr6P_5rt_wrqXgSMGORsLc7s=.387c4b53-0c31-4785-a266-c3dc822fbf38@github.com>
 <SlMak729mZwqF-TPz1bu3cxnKY4JS61tKtuoNEFu7Lg=.c3faed6c-a965-400b-ac23-0fb1dc1cbd65@github.com>
Message-ID: <V8Jm9mVgJt9RXt4W_w_UUp-IA6iyRODEJnjkuo6CsCE=.0a17f3bb-20bb-4b56-ba0f-2f27ac5519ed@github.com>

On Mon, 20 Oct 2025 10:03:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sean Coffey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further help message tweaks
>
> src/hotspot/share/services/diagnosticCommand.hpp line 361:
> 
>> 359:     return "Print all platform threads, and mounted virtual threads, "
>> 360:            "with stack traces. The Thread.dump_to_file command will "
>> 361:            "print all threads to a file.";
> 
> I'm still in two minds about having it mention Thread.dump_to_file. If it is mentioned then it would be better to put in a line break and use "may be used to" that rather than "will".

yes - happy to tweak this in follow on issue if necessary. I think it reads fine as is but let me know the final format and I'll file a new PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27861#discussion_r2444735331

From dbriemann at openjdk.org  Mon Oct 20 15:04:03 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Mon, 20 Oct 2025 15:04:03 GMT
Subject: RFR: 8370240: [PPC64] jhsdb jstack cannot handle continuation stub
Message-ID: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>

This is a port of 8369979 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.

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

Commit messages:
 - 8370240: [PPC64] jhsdb jstack cannot handle continuation stub

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

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

From fandreuzzi at openjdk.org  Mon Oct 20 16:41:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 20 Oct 2025 16:41:05 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
 <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
Message-ID: <vYVkf0HIaSQEIOZoXyNa2KkVUUwFwPLRU3YaG93eoiE=.6e725bd5-33ad-4d47-82c7-a469f288851d@github.com>

On Thu, 16 Oct 2025 22:31:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert
>>  - replace
>
> The approach looks okay to me. Thank you for taking care about this issue!

Hi @sspitsyn, @dholmes-ora, @lmesnik, I applied all your suggestions. This PR is ready for another look when you have time.

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3422860973

From duke at openjdk.org  Mon Oct 20 17:37:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:37:44 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v3]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <EBxwdE3akdiEKYckVZGX-VLdDBeGHkFYzvNkye4_XQw=.3fbaa8dc-3fde-423f-999c-ff2a15ede3c1@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - j.l.management with generic API docs
 - Revert "Move from j.l.management to com.sun.management etc."
   
   This reverts commit 6431310109a02ec5c34f877a1c690afb00193043.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/64313101..b03db63e

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

  Stats: 186 lines in 11 files changed: 35 ins; 143 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

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

From duke at openjdk.org  Mon Oct 20 17:50:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:50:05 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
Message-ID: <qg1Bn8Hwxdd_QQHbIeOzZPZijQUXI9vLX9Vl4mZBY8k=.4f536c8a-66ee-443a-8ff9-34a023708365@github.com>

On Wed, 15 Oct 2025 10:14:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move from j.l.management to com.sun.management etc.
>
> Or:
> 
> 
>      * @implNote Time calculation is implementation-specific, and may include details
> 	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
> 	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

Thanks for the suggested API docs @kevinjwalls! I pushed a proposal to use j.l.management, with the proposed generic API docs.

I dropped "may" and "any" from the paragraph about `-1` return value from @kevinjwalls original suggestion:

     * This method return {@code -1} if the platform does
     * not support this operation or the information is not
     * available.

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3423134361

From duke at openjdk.org  Mon Oct 20 17:44:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:44:05 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v4]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <CdFU-mIZLpsyvo6OYlS8zoLHsZFcneghwBRJ7HhdniE=.636452d0-bcc8-414b-80f4-0ed381feabf7@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Remove tabs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/b03db63e..8d83dd97

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

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

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

From sspitsyn at openjdk.org  Mon Oct 20 18:29:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 18:29:05 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <Kjr97B0c7Zct7rbCyDEGOu4qJjEhqMWgwZqojDVMY1Q=.62182532-f9be-4968-829a-a48d8f9282f7@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> I'm not sure this functionality is really JVMTI worthy but if Jonas thinks this is useful for GC profiling then I will take his word for it.

Yes. I asked Jonas about it when we started our conversation and I rely on his justification which is in the enhancement description.

> This seems to contradict the description that it could be relative to a value in the future and hence negative - thus it can't be "unsigned". But then I don't see how it can be as described - for this timer to be useful it must be tracking nanoseconds of CPU time consumed by GC since CPU time tracking commenced, sometime after VM startup. This has to be similar to how thread CPU time is defined.

Good catch, thanks. Fixed now.

> Also the hex value represents JDK 23 not 25.

Good catch, thanks. Fixed now.

> If it isn't supported then you can't have the capability and so won't reach here.

Good comment. In fact, I've already made a decision to move this to the capability check. But it seems, it also needs to be fixed this way for `GetCurrentThreadCpuTime()` and `GetThreadCpuTime()`.

>> +       Universe::heap()->is_shutting_down()) {
>> +       *nanos_ptr = -1;
> 
> This seems wrong to me and violates the timer-info spec of this timer not jumping backwards. I think you have to cache the last returned value for this function and if you cannot calculate an updated value because of VM shutdown, then that previous value should be returned.

I agree. I've already noticed this issue and was thinking where and how to fix it. Thank you for the suggestion. It can be fixed this way but I feel it is better to fix on the GC side. Will discuss it with Jonas.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423268108

From sspitsyn at openjdk.org  Mon Oct 20 19:04:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 19:04:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
Message-ID: <_dyneYvZ5cJjriz-Mt1woRWD4LfgppeF2dJybclDo2I=.3049be57-dccd-4378-876c-b7780bf8c1f7@github.com>

On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).

Alan, thank you for looking at this, the comments and good questions. I agree, we need to look at some level of completeness here. It includes the process CPU time and potentially more functionality to support modern GC's (I hope to get more insight from the GC team here). One question I've got is about all these timers and a possibility to reuse some of them. Is it right to have new timer for each CPU metric? We need some kind of overall design for all this. As I've posted earlier in reply to David for this enhancement, I rely on Jonas's justification which is in the enhancement description.

> As a general point, the JVMTI spec doesn't have much support for monitoring GC. It has GC start/end events that date from the original spec when collectors were all STW and it hasn't evolved since to model more modern collectors.

Yes, support for modern collectors is on the table for some time.  Now seems to be a good time to make some steps in this direction.

> I'm sure CPU time spend on GC is important to many profilers but I'm also wondering if JVMTI is the right API for modern profilers to be using. JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.

I hope, Jonas has answered this.

> (in passing, I see GetAvailableProcessors is in the Timers section of the spec, is that the right place for this?)

Yes, it seems this function is a little bit out of this section scope. But I do not see a better section for this, and it does not deserve its own section yet. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423360087

From sspitsyn at openjdk.org  Mon Oct 20 19:17:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 19:17:05 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <-xJ-7eFcpzLYfOtrQlhE9ejmcwz1WM7FplEQtmTCADc=.2ec0d270-3e7f-4862-8967-1aa245bf5c5a@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> I'm wondering, would a user trying to call GetTotalGCCpuTime if can_get_gc_cpu_time is not successfully set to 1 be undefined behavior? The specs say "To possess a capability, the agent must add the capability (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#capability). If yes maybe we can discard the extra call to os::is_thread_cpu_time_supported in JvmtiEnv::GetTotalGCCpuTime? That seems to align with the pattern to not have that check in the other methods as you pointed out.

Right thinking, thanks. In fact, I had a plan to move this check to the capability side after the week ends. :)

> Should this be called GetTotalGCCpuTimerInfo?

I was already thinking on this for some time. I wanted to generalize this timer a little bit for a case if we ever decide to add more GC related functions. I'm not sure that all timers have to be strictly bound to the `CpuTime` function` and can be potentially reused for some other cases.

> There may be two issues with the patch as is:
> Calling GetTotalGCCpuTime in Agent_OnLoad can cause crash (since CollectedHeap::gc_threads_do do not protect against races on VM startup/shutdown).
>
> If GetTotalGCCpuTime is invoked in a callback for GC start/end, this will cause a deadlock as the Heap_lock is already held. The MutexLocker hl(Heap_lock) pattern was introduced to avoid races that could happen from internal usage in G1 of CPUTimeUsage::GC::total() during shutdown. I could recall this wrong but I think the usage Heap_lock (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of Universe::_is_shutting_down. I will ask @walulyai for his thoughts.

It is nice you have caught this early. It would be nice to sort out this issue, and it is better to fix it on the GC side. I'd suggest to file a bug to separate this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423402965

From lmesnik at openjdk.org  Mon Oct 20 20:43:06 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 20 Oct 2025 20:43:06 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
Message-ID: <znrXyE8m6tr9mjKkSyGUJaP7EBcfeHR2re6A3Zumqn8=.a9d6e5c5-5a2d-45a2-bb6b-6fed28463717@github.com>

On Fri, 17 Oct 2025 20:16:28 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix tool call

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 66:

> 64:     @AfterAll
> 65:     static void stopChild() throws Exception {
> 66:         child.destroy();

Is it possible to let the process to complete normally instead of killing it?  (by writing into stream?)
So test can verify that process is exited with code 0 and nothing is broken by this attaching attempt.

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

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3357862476
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446072341

From kbarrett at openjdk.org  Mon Oct 20 20:56:06 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 20 Oct 2025 20:56:06 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <ealn_1aUb8RSGHtU0rSU2QXw0NnKSbLVzQU0XOusP28=.a18d6e0f-b721-4929-9d29-870fc1060353@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett 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 stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

I forgot to update gtests to use the newly introduced wrapper headers. I'll deal with that later as a separate change,
to avoid making this one even bigger with not very interesting changes to a bunch more files.

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3423683169

From kbarrett at openjdk.org  Mon Oct 20 21:00:07 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 20 Oct 2025 21:00:07 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ol4S2Q_rbwLwGQeZEYH4al1MFGB2-KrFSfLAaP4y16M=.3b95fd2f-a598-4842-9afc-b961d496fb56@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
 <ol4S2Q_rbwLwGQeZEYH4al1MFGB2-KrFSfLAaP4y16M=.3b95fd2f-a598-4842-9afc-b961d496fb56@github.com>
Message-ID: <gC8igKGYKLcIi17oTJUcLLT0Aw4adBgaIyMb0WgcPD4=.ae5b1824-a2a8-4287-ab69-c2691a9816ac@github.com>

On Mon, 20 Oct 2025 09:15:14 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> [...] I would have liked more of the c++ library included (like tuples, optional and expected), but this is a good start.

This PR is intentionally quite limited; it doesn't add anything to the set of
what's permitted. It is instead about establishing that such additions are
possible, and a framework for doing so.

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

PR Comment: https://git.openjdk.org/jdk/pull/27601#issuecomment-3423694560

From sspitsyn at openjdk.org  Mon Oct 20 21:05:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 21:05:25 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v4]
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <5ZWuvRfM6nTcjIkNRpjYYHTlhNwuBEN0SK4lchzxVNw=.b655df31-9696-45ff-94cc-70c53b459d76@github.com>

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  Review: address some review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27879/files
  - new: https://git.openjdk.org/jdk/pull/27879/files/d816a56d..6ac238eb

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

  Stats: 10 lines in 3 files changed: 1 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27879.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27879/head:pull/27879

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

From amenkov at openjdk.org  Mon Oct 20 21:06:08 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Mon, 20 Oct 2025 21:06:08 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
Message-ID: <xf_R4XhoGBHuq7T33SYDNDCdGn7vYGT5g9a-G2DmnZg=.f3858bfe-5e28-4333-bba5-fba5e464bf56@github.com>

On Fri, 17 Oct 2025 20:16:28 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix tool call

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 35:

> 33: import java.io.InputStream;
> 34: import java.util.Objects;
> 35: import java.util.concurrent.TimeUnit;

Unused imports

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 99:

> 97: 
> 98:         ProcessBuilder pb = new ProcessBuilder(jcmd.getCommand());
> 99:         OutputAnalyzer out = new OutputAnalyzer(pb.start());

I'd suggest to use `jdk.test.lib.dcmd.PidJcmdExecutor`
Then this can be simplified to something like


OutputAnalyzer out = new PidJcmdExecutor().execute("JVMTI.agent_load some.jar");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446116204
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446119986

From stefank at openjdk.org  Mon Oct 20 21:40:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 20 Oct 2025 21:40:03 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
 <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>
Message-ID: <jUyva7bG0i9CIhDRa_ohAHYwFXCWrGUKOhzqURYbNRs=.cca0ef3c-06e1-44a4-98c3-f7095cdfcc41@github.com>

On Fri, 17 Oct 2025 14:57:11 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/cds/heapShared.cpp line 355:
>> 
>>> 353: }
>>> 354: 
>>> 355: bool HeapShared::is_loading_mapping_mode() {
>> 
>> I think `is_loading_mapping_mode()` should be removed and we should use only `is_loading_streaming_mode()`. This will make it easy to find all the places that checks between mapping/streaming. Same for `is_writing_xxx_mode()`.
>> 
>> Also, instead of having a tri-state of `_heap_load_mode`, it's better to have two boolean states:
>> 
>> - _is_loading_heap
>> - _is_loading_heap_streaming_mode
>> 
>> The first boolean is the main switch, but most of the code will be checking only the second boolean.
>
> Okay. @stefank is having a look at fixing this.

I've sort-of implemented the second part of your comment about removing the tri-state:
https://github.com/fisk/jdk/compare/8326035_JEP_object_streaming_v6...stefank:jdk:8326035_JEP_object_streaming_v6_stefank

The enum had *four* states (`uninitialized`, `mapping`, `streaming`, `none`) and while reading this PR the `none` part seemed unusual. After working on the proposed patch I think the `none` value served a purpose, but let's see if a patch without it makes sense.

The patch still uses an enum instead of two booleans. I think that makes the code more readable because we encode the three states with three enum values. If we were to use two booleans we would end up with four possible states and then the reader of the code would have to figure out which of the forth state is an invalid state. I think what we have in the patch above is safer. (Let's revisit this if this still is a blocker)

So, I removed `none` and added strict asserts that you are not allowed to ask for the mode until the variable has transitioned away from `uninitialized` to either `mapping` or `streaming`. After the variable has been initialized the questions are binary and you have `is_loading_mapping_mode() == !is_loading_streaming_mode()`. I don't see the appeal to remove one of these two functions, because that just adds negation to the code and that makes it harder to read. (We can experiment with that in a separate patch)

I tried to take it even further and join these `is_loading` functions with the `is_archived_heap_in_use` and the `is_in_use` properties, but that hit problems with error-edge cases. I have a feeling that the `none` value dealt with these problems.

Some more details about the edge-case problems:

During loading of the heap archive there is a duration where we have decided that we are going to load the archived heap and what loading mode to use, but the archive has not been loaded enough have the `is_archived_heap_in_use` function return `true`. During these early stages we must use the `is_loading` and `is_loading_` functions. After `is_archived_heap_in_use` starts to return the correct value, the code likely needs to use that function instead of the `is_loading` functions. Some parts of the AOT/CDS code will bug out if you try to use the `is_loading` functions after an error.

So, I've tried to keep the usages of `is_loading` functions inside AOT/CDS code. The `is_archived_heap_in_use`, or one of it's sub-components (E.g. `AOTMappedHeapLoader:is_in_use()`), are used in both later stages of the AOT/CDS code and in code only adjacent to AOT/CDS.

In addition to removing the `none"` state the patch also includes a couple of small tweaks:

* Move some dispatching to "mapping" and "streaming" code so that the `is_loading_` functions could be kept inside the HeapShared code.
* Move `is_` functions to heapShared.inline.hpp added to get rid of some extra calls.
* Fix some log error messages for inconsistent JVM flags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2446184309

From dholmes at openjdk.org  Tue Oct 21 01:10:39 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Oct 2025 01:10:39 GMT
Subject: RFR: 8370257: Remove ProblemListed tests from ProblemList.txt
Message-ID: <vKJbJ5kFcfx4lBVTuH0_xyz2GY_SHvl7lmnhvamQM4Q=.7789239f-0527-4be4-a261-eb64150cf487@github.com>

The tests were ProblemListed due to warnings generated by the LockingMode changes leading up to its removal by JDK-8344261 (sub-tasks thereof). Those entries can now be removed.

Testing
- tiers 1-3

Thanks

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

Commit messages:
 - 8370257: Remove ProblemListed tests from ProblemList.txt

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

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

From cjplummer at openjdk.org  Tue Oct 21 03:17:13 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 21 Oct 2025 03:17:13 GMT
Subject: RFR: 8370257: Remove ProblemListed tests from ProblemList.txt
In-Reply-To: <vKJbJ5kFcfx4lBVTuH0_xyz2GY_SHvl7lmnhvamQM4Q=.7789239f-0527-4be4-a261-eb64150cf487@github.com>
References: <vKJbJ5kFcfx4lBVTuH0_xyz2GY_SHvl7lmnhvamQM4Q=.7789239f-0527-4be4-a261-eb64150cf487@github.com>
Message-ID: <d4woU11LDSrMGePiv0wE0VcLsNGguCa8BRnjuZiOlY0=.1909fb8d-a298-480b-bcf6-f3a8f78debfb@github.com>

On Tue, 21 Oct 2025 00:56:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The tests were ProblemListed due to warnings generated by the LockingMode changes leading up to its removal by JDK-8344261 (sub-tasks thereof). Those entries can now be removed.
> 
> Testing
> - tiers 1-3
> 
> Thanks

Looks good. Thanks for taking care of this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27910#pullrequestreview-3358630807

From cjplummer at openjdk.org  Tue Oct 21 03:20:08 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 21 Oct 2025 03:20:08 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
Message-ID: <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>

On Mon, 20 Oct 2025 06:59:42 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
>> 
>> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
>> 
>> 
>> ----------------- 646689 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
>> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
>> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
>> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 
>> 
>> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
>> 
>> 
>> ----------------- 646841 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
>> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
>> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
>> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
>> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
>> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
>> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
>> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
>> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
>> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
>> 0x00007f4a08fc31bb JavaCalls::call_virtu...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcase

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithXComp.java line 40:

> 38:  * @bug 8370176
> 39:  * @requires vm.hasSA
> 40:  * @requires os.family == "linux"

Do Windows and OSX have a similar problem that should be fixed also?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2445943475

From dholmes at openjdk.org  Tue Oct 21 04:07:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Oct 2025 04:07:12 GMT
Subject: RFR: 8370257: Remove ProblemListed tests from ProblemList.txt
In-Reply-To: <d4woU11LDSrMGePiv0wE0VcLsNGguCa8BRnjuZiOlY0=.1909fb8d-a298-480b-bcf6-f3a8f78debfb@github.com>
References: <vKJbJ5kFcfx4lBVTuH0_xyz2GY_SHvl7lmnhvamQM4Q=.7789239f-0527-4be4-a261-eb64150cf487@github.com>
 <d4woU11LDSrMGePiv0wE0VcLsNGguCa8BRnjuZiOlY0=.1909fb8d-a298-480b-bcf6-f3a8f78debfb@github.com>
Message-ID: <1c3xeNDq8CSBnD1ESxer9qf0zpsLNllcuPPDBLE9IOA=.43e17754-8b68-4ac4-a8a4-69b4e2df3f23@github.com>

On Tue, 21 Oct 2025 03:14:52 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The tests were ProblemListed due to warnings generated by the LockingMode changes leading up to its removal by JDK-8344261 (sub-tasks thereof). Those entries can now be removed.
>> 
>> Testing
>> - tiers 1-3
>> 
>> Thanks
>
> Looks good. Thanks for taking care of this.

Thanks for the review @plummercj .

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

PR Comment: https://git.openjdk.org/jdk/pull/27910#issuecomment-3424583505

From dholmes at openjdk.org  Tue Oct 21 04:07:14 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 21 Oct 2025 04:07:14 GMT
Subject: Integrated: 8370257: Remove ProblemListed tests from ProblemList.txt
In-Reply-To: <vKJbJ5kFcfx4lBVTuH0_xyz2GY_SHvl7lmnhvamQM4Q=.7789239f-0527-4be4-a261-eb64150cf487@github.com>
References: <vKJbJ5kFcfx4lBVTuH0_xyz2GY_SHvl7lmnhvamQM4Q=.7789239f-0527-4be4-a261-eb64150cf487@github.com>
Message-ID: <Nao8K8pZW4WJ4l6cs9oLVAWjEYHp9tLk1z9ubwtdyuM=.2580b11f-626e-4526-8fa9-0f8a960bf0f4@github.com>

On Tue, 21 Oct 2025 00:56:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The tests were ProblemListed due to warnings generated by the LockingMode changes leading up to its removal by JDK-8344261 (sub-tasks thereof). Those entries can now be removed.
> 
> Testing
> - tiers 1-3
> 
> Thanks

This pull request has now been integrated.

Changeset: eee29088
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eee2908853342ae305c200f7ec37081ea939a4fa
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8370257: Remove ProblemListed tests from ProblemList.txt

Reviewed-by: cjplummer

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

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

From clanger at openjdk.org  Tue Oct 21 05:34:02 2025
From: clanger at openjdk.org (Christoph Langer)
Date: Tue, 21 Oct 2025 05:34:02 GMT
Subject: RFR: 8370240: [PPC64] jhsdb jstack cannot handle continuation stub
In-Reply-To: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
References: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
Message-ID: <c2G3r-DrdIQmICbDigKR3ZFY5VheH016H-3Z15Yqvw4=.0f82589c-25f1-4e29-8a21-f8afaf9449bf@github.com>

On Mon, 20 Oct 2025 14:56:32 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> This is a port of 8369979 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
> It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.

test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java line 40:

> 38:  * @bug 8369505
> 39:  * @requires vm.hasSA
> 40:  * @requires (os.arch == "amd64" | os.arch == "x86_64" | os.arch == "aarch64" | os.arch == "riscv64" | os.arch == "ppc64" | os.arch == "ppc64le")

Is there still an arch that is unsupported? Otherwise the whole line can be dropped, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27902#discussion_r2446763380

From ysuenaga at openjdk.org  Tue Oct 21 05:47:05 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 21 Oct 2025 05:47:05 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
Message-ID: <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>

On Mon, 20 Oct 2025 19:44:07 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase
>
> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithXComp.java line 40:
> 
>> 38:  * @bug 8370176
>> 39:  * @requires vm.hasSA
>> 40:  * @requires os.family == "linux"
> 
> Do Windows and OSX have a similar problem that should be fixed also?

This problem is in mixed mode (`PStack`) only, thus we need to skip OSX because [you mentioned](https://github.com/openjdk/jdk/pull/27728#issuecomment-3392919979) mixed mode is not supported on OSX.

In Windows, I'm not sure, but I guess we need to consider `UNWIND_INFO` like DWARF in Linux, however it hasn't done yet. Thus I didn't added Windows here.
https://learn.microsoft.com/cpp/build/exception-handling-x64

Actually I could not see all of stacks as following in mixed mode. It works in normal mode (without `--mixed`) of course. (I tested it on Windows 11 x64, upstream JDK built by VS 2022)

----------------- 13 -----------------
"Reference Handler" #15 daemon prio=10 tid=0x00000207280b9f70 nid=12684 waiting on condition [0x000000aaf6aff000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007fffa6b45844      ntdll!NtWaitForAlertByThreadId + 0x14
0x00000000ffffffff              ????????

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2446778835

From sspitsyn at openjdk.org  Tue Oct 21 07:14:07 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 07:14:07 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
Message-ID: <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>

On Fri, 17 Oct 2025 20:16:28 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix tool call

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 47:

> 45: 
> 46:     jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks));
> 47:     jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VM_START, nullptr);

Nit: Even though it is normally works well it'd be better to check and handle the `jvmtiError` code returned from the JVMTI functions. You can easily find some examples to follow. Also, the indent for native code has to be 2, not 4.  It is possible, you can find some tests where this kind of check/handling is missed or the indent is incorrect. It does not mean we should have these bad habits with new tests. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2446956647

From sspitsyn at openjdk.org  Tue Oct 21 07:59:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 07:59:10 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v2]
In-Reply-To: <jLcTWqm4cz7c863ysJVqjbdiaQlERnpJZHHB3F4AECo=.04631781-37ff-49d8-a206-78b4c15a414a@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <jLcTWqm4cz7c863ysJVqjbdiaQlERnpJZHHB3F4AECo=.04631781-37ff-49d8-a206-78b4c15a414a@github.com>
Message-ID: <yN4RBa1BoiF6Qsm0lxXvG1K6WF01XV2ijodkahvMscA=.759aef17-3d36-4e2f-a75e-f7e02446a5b9@github.com>

On Sat, 18 Oct 2025 17:24:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
>> 
>> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
>> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
>> 
>> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
>> 
>> The location should be zero for JNI access.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed comment

src/hotspot/share/prims/jvmtiExport.cpp line 2226:

> 2224:     javaVFrame *jvf = thread->last_java_vframe(&reg_map);
> 2225:     method = jvf->method();
> 2226:     address = jvf->method()->code_base();

Nit: I'm thinking if this code can be simplified a little bit if the same approach with `reg_map` can be used for interpreter frame as well.

src/hotspot/share/prims/jvmtiExport.cpp line 2332:

> 2330:     javaVFrame *jvf = thread->last_java_vframe(&reg_map);
> 2331:     method = jvf->method();
> 2332:     address = jvf->method()->code_base();

Nit: Same question as above on a potential simplification by unifying the interpreter and compile frame cases.

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/TestFieldsEventsFromJNI.java line 29:

> 27:  * @bug 8224852
> 28:  * @run main/othervm/native -agentlib:JvmtiFieldEventsFromJNI TestFieldsEventsFromJNI
> 29:  * @run main/othervm/native -agentlib:JvmtiFieldEventsFromJNI -Xcomp TestFieldsEventsFromJNI

Nit: It is convenient when the test folder and the Java file have the same name. Many tests in the `serviceability/jvmti` folder follow this rule. So, I'd suggest to get rid of the `Test` prefix in this class name. An additional advantage would be that the class name is shorter. :)

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/TestFieldsEventsFromJNI.java line 48:

> 46: 
> 47:     public static void main(String[] args) throws InterruptedException {
> 48:         System.loadLibrary("JvmtiFieldEventsFromJNI");

Nit: Is this really needed? In fact, we have it in many tests though.

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 43:

> 41:   jni->DeleteLocalRef(object_class);
> 42:   return obj_class_name;
> 43: }

Nit: Would it be good to add this into `jvmti_common.hpp`?

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 102:

> 100:   deallocate(jvmti,jni, f_name);
> 101: 
> 102: 

Nit: Unneeded empty lines: 68, 102 and 137.

test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 335:

> 333:   check_jvmti_status(jni, err, "get_field_name: error in JVMTI GetFieldName call");
> 334:   deallocate(jvmti,jni, signature);
> 335:   deallocate(jvmti,jni, generic);

Nit: The lines 334 and 335 miss space after comma in the argument lists. Also, it is better to pass `nullptr` instead of `&generic`, so there would not be need to have this local and to deallocate the returned string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2447046252
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2447054396
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2447066803
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2447075224
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2447101802
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2447108290
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2447094326

From rrich at openjdk.org  Tue Oct 21 08:58:03 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Oct 2025 08:58:03 GMT
Subject: RFR: 8370240: [PPC64] jhsdb jstack cannot handle continuation stub
In-Reply-To: <c2G3r-DrdIQmICbDigKR3ZFY5VheH016H-3Z15Yqvw4=.0f82589c-25f1-4e29-8a21-f8afaf9449bf@github.com>
References: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
 <c2G3r-DrdIQmICbDigKR3ZFY5VheH016H-3Z15Yqvw4=.0f82589c-25f1-4e29-8a21-f8afaf9449bf@github.com>
Message-ID: <wnU-spcTizSQNRHbdbZa8dRLfFfP3LejNwQEtmrx9hI=.d36db29a-4e16-4045-baac-fbe7c776a578@github.com>

On Tue, 21 Oct 2025 05:31:25 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> This is a port of 8369979 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
>> It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.
>
> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java line 40:
> 
>> 38:  * @bug 8369505
>> 39:  * @requires vm.hasSA
>> 40:  * @requires (os.arch == "amd64" | os.arch == "x86_64" | os.arch == "aarch64" | os.arch == "riscv64" | os.arch == "ppc64" | os.arch == "ppc64le")
> 
> Is there still an arch that is unsupported? Otherwise the whole line can be dropped, no?

I think it can be removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27902#discussion_r2447333892

From dbriemann at openjdk.org  Tue Oct 21 09:07:30 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Tue, 21 Oct 2025 09:07:30 GMT
Subject: RFR: 8370240: [PPC64] jhsdb jstack cannot handle continuation stub
 [v2]
In-Reply-To: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
References: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
Message-ID: <RNsAORNRumBhAue6o6Ao4xhlmxc2bOMzHgbqkCFWkTM=.22446acc-b7cc-4bd1-b09c-96d1abc4b3ad@github.com>

> This is a port of 8369979 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
> It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.

David Briemann has updated the pull request incrementally with one additional commit since the last revision:

  remove unnecessary requires

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27902/files
  - new: https://git.openjdk.org/jdk/pull/27902/files/3aedfd5c..056a8b59

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

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

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

From mdoerr at openjdk.org  Tue Oct 21 09:20:02 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 21 Oct 2025 09:20:02 GMT
Subject: RFR: 8370240: [PPC64] jhsdb jstack cannot handle continuation stub
 [v2]
In-Reply-To: <RNsAORNRumBhAue6o6Ao4xhlmxc2bOMzHgbqkCFWkTM=.22446acc-b7cc-4bd1-b09c-96d1abc4b3ad@github.com>
References: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
 <RNsAORNRumBhAue6o6Ao4xhlmxc2bOMzHgbqkCFWkTM=.22446acc-b7cc-4bd1-b09c-96d1abc4b3ad@github.com>
Message-ID: <IRPk7rA1Sl9GOXd_tq1aBleqdZCgwKktO7B3R58iuRY=.5db66ef1-9699-45f0-9890-661ac55866eb@github.com>

On Tue, 21 Oct 2025 09:07:30 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> This is a port of 8369979 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
>> It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessary requires

LGTM.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27902#pullrequestreview-3359624622

From rrich at openjdk.org  Tue Oct 21 09:29:06 2025
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 21 Oct 2025 09:29:06 GMT
Subject: RFR: 8370240: [PPC64] jhsdb jstack cannot handle continuation stub
 [v2]
In-Reply-To: <RNsAORNRumBhAue6o6Ao4xhlmxc2bOMzHgbqkCFWkTM=.22446acc-b7cc-4bd1-b09c-96d1abc4b3ad@github.com>
References: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
 <RNsAORNRumBhAue6o6Ao4xhlmxc2bOMzHgbqkCFWkTM=.22446acc-b7cc-4bd1-b09c-96d1abc4b3ad@github.com>
Message-ID: <26xuAk-6jhmIYwaGkSLNnhhLEPRRPBGVJ-UQQtuD89Y=.e64dcad7-52be-41dd-afd1-32cdf6409e31@github.com>

On Tue, 21 Oct 2025 09:07:30 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> This is a port of 8369979 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
>> It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessary requires

Looks good.
Cheers, Richard.

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

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27902#pullrequestreview-3359668574

From fandreuzzi at openjdk.org  Tue Oct 21 09:31:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:31:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v14]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <og-MzkWyLi7rxNct6NRjNzd1ySH4z2hQgzjtFQhUuRQ=.d033e524-3b89-4963-a03b-f4cdf284b92a@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with five additional commits since the last revision:

 - jvmti errors
 - indent
 - close
 - rephrase
 - PidJcmdExecutor. unused import. cc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/30b2cf96..925f9fc8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=12-13

  Stats: 59 lines in 2 files changed: 19 ins; 14 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

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

From fandreuzzi at openjdk.org  Tue Oct 21 09:31:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:31:42 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <xf_R4XhoGBHuq7T33SYDNDCdGn7vYGT5g9a-G2DmnZg=.f3858bfe-5e28-4333-bba5-fba5e464bf56@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <xf_R4XhoGBHuq7T33SYDNDCdGn7vYGT5g9a-G2DmnZg=.f3858bfe-5e28-4333-bba5-fba5e464bf56@github.com>
Message-ID: <JdmjkJ85SqHoUfwvC1EvKbJx8njVF9Yy5k2HaevpdeM=.5e3f9ffc-f22a-4eea-8ebf-8cfd1e0d7b04@github.com>

On Mon, 20 Oct 2025 21:01:08 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix tool call
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 35:
> 
>> 33: import java.io.InputStream;
>> 34: import java.util.Objects;
>> 35: import java.util.concurrent.TimeUnit;
> 
> Unused imports

bd4b98a7ad038a4516db7caa8d62204ba760a79c

> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 99:
> 
>> 97: 
>> 98:         ProcessBuilder pb = new ProcessBuilder(jcmd.getCommand());
>> 99:         OutputAnalyzer out = new OutputAnalyzer(pb.start());
> 
> I'd suggest to use `jdk.test.lib.dcmd.PidJcmdExecutor`
> Then this can be simplified to something like
> 
> 
> OutputAnalyzer out = new PidJcmdExecutor().execute("JVMTI.agent_load some.jar");

Thanks, fixed in bd4b98a7ad038a4516db7caa8d62204ba760a79c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447476586
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447476248

From fandreuzzi at openjdk.org  Tue Oct 21 09:31:43 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:31:43 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>
Message-ID: <MkqgOBIlKQflEWsM92DgkKXyeoeRbnRAaLklgILDtw0=.9584a734-e082-4694-bf10-f9c41f30ee09@github.com>

On Tue, 21 Oct 2025 07:08:10 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix tool call
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 47:
> 
>> 45: 
>> 46:     jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks));
>> 47:     jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VM_START, nullptr);
> 
> Nit: Even though it is normally works well it'd be better to check and handle the `jvmtiError` code returned from the JVMTI functions. You can easily find some examples to follow. Also, the indent for native code has to be 2, not 4.  It is possible, you can find some tests where this kind of check/handling is missed or the indent is incorrect. It does not mean we should have these bad habits with new tests. :)

Fixed in a401f0a118785f600e70ca0099802ff05e967bc9 and 925f9fc828597f920e4b800d63428e414f8b0345. I thought the error could be printed with `jvmti->GetErrorName`, but I guess that would introduce unnecessary complication. Let me know what you think @sspitsyn.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447475060

From fandreuzzi at openjdk.org  Tue Oct 21 09:43:21 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:43:21 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v15]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <Ler7QHsjSwjk3Ywx-MsqbhxOPomdgyu-WM0gjkxX86c=.7958318f-5b18-4682-b1c5-5e1df6395037@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  empty stderr

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/925f9fc8..60d6fdff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27766&range=13-14

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

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

From fandreuzzi at openjdk.org  Tue Oct 21 09:43:24 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:43:24 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <znrXyE8m6tr9mjKkSyGUJaP7EBcfeHR2re6A3Zumqn8=.a9d6e5c5-5a2d-45a2-bb6b-6fed28463717@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <znrXyE8m6tr9mjKkSyGUJaP7EBcfeHR2re6A3Zumqn8=.a9d6e5c5-5a2d-45a2-bb6b-6fed28463717@github.com>
Message-ID: <Ya-VpLXP4M_w9rn-5ri_aYvg1ThFnN-d8AM4E6yYl8A=.6eafcd95-0321-4ef2-9443-2a7f013171c1@github.com>

On Mon, 20 Oct 2025 20:40:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix tool call
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 66:
> 
>> 64:     @AfterAll
>> 65:     static void stopChild() throws Exception {
>> 66:         child.destroy();
> 
> Is it possible to let the process to complete normally instead of killing it?  (by writing into stream?)
> So test can verify that process is exited with code 0 and nothing is broken by this attaching attempt.

Yeah that sounds reasonable, thanks. Please check the latest revision of the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2447510551

From fandreuzzi at openjdk.org  Tue Oct 21 09:47:52 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 09:47:52 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  cc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/60d6fdff..ba3dc024

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

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

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

From duke at openjdk.org  Tue Oct 21 10:36:23 2025
From: duke at openjdk.org (GennadiyKrivoshein)
Date: Tue, 21 Oct 2025 10:36:23 GMT
Subject: Integrated: 8020207: jconsole fails connecting over SSL using
 service:jmx:rmi://...jndi...
In-Reply-To: <zrRemP36pH7JxZPw7tk117ugwJ20KQPFDkOGjBoYTIE=.0be695f2-9190-4816-b276-59ddc3ec3bb6@github.com>
References: <zrRemP36pH7JxZPw7tk117ugwJ20KQPFDkOGjBoYTIE=.0be695f2-9190-4816-b276-59ddc3ec3bb6@github.com>
Message-ID: <Srj3WVJv2CQeIQ5G-J3flmtPVu6EDxJK_n_xvnJ-FW8=.7243644b-3c95-46b5-bc7d-bc1c4dd69b1c@github.com>

On Fri, 3 Oct 2025 12:00:13 GMT, GennadiyKrivoshein <duke at openjdk.org> wrote:

> This is the fix for the https://bugs.openjdk.org/browse/JDK-8020207, JConsole fails connecting over SSL using a string with a JMXServiceURL.
> 
> The cause of the issue is a connection to the RMI registry. If the registry and agent use SSLSockets and JConsole is trying to connect to the agent using "service:jmx:rmi..." URL, ProxyClient of the JConsole does not attempt to use SSL for communication with the registry, it always tries to connect using not secured Socket.
> 
> I would suggest to parse the JMXServiceURL and check the SSL config for the RMI registry for one specific case:
> 
> -  the schema of the JMXServiceURL is "rmi"
> -  the path of the JMXServiceURL is "/jndi/"
> -  the schema of the RMI registry URI is "rmi"
> -  the path of the RMI registry URI is "/jmxrmi".

This pull request has now been integrated.

Changeset: ea7186a8
Author:    Gennadiy Krivoshein <gennadiy.krivoshein at bell-sw.com>
Committer: Dmitry Chuyko <dchuyko at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea7186a87f990346fe6af6d4a36989d87e6f98d1
Stats:     20 lines in 1 file changed: 18 ins; 0 del; 2 mod

8020207: jconsole fails connecting over SSL using service:jmx:rmi://...jndi...

Reviewed-by: kevinw

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

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

From duke at openjdk.org  Tue Oct 21 11:15:17 2025
From: duke at openjdk.org (Ruben)
Date: Tue, 21 Oct 2025 11:15:17 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
Message-ID: <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>

On Wed, 15 Oct 2025 14:00:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge from the main branch
>>  - Address review comments
>>  - Address review comments
>>  - Address review comments
>>  - The patch is contributed by @TheRealMDoerr
>>  - Offset the deoptimization handler entry point
>>    
>>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>>  - Revert "Ensure stub code is not adjacent to a call"
>>  - Ensure stub code is not adjacent to a call
>>  - Address review comments
>>  - 8365047: Remove exception handler stub code in C2
>>    
>>    The C2 exception handler stub code is only a trampoline to the
>>    generated exception handler blob. This change removes the extra
>>    step on the way to the generated blob.
>>    
>>    According to some comments in the source code, the exception handler
>>    stub code used to be patched upon deoptimization, however presumably
>>    these comments are outdated as the patching upon deoptimization happens
>>    for post-call NOPs only.
>
> One probably related issue on linuxaarch64 while testing "gc/epsilon/TestObjects.java":
> SIGSEGV in caller_is_deopted:
> 
> 
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x5531b8]  caller_is_deopted(JavaThread*)+0x2f8  (nativeInst_aarch64.hpp:536)
> V  [libjvm.so+0x555000]  Runtime1::move_mirror_patching(JavaThread*)+0x20  (c1_Runtime1.cpp:1400)
> v  ~RuntimeStub::C1 Runtime load_mirror_patching_blob 0x0000f7cf038f316c
> 
> 
> 
> siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000f7cf03c60000
> 
> 
> That address is at the end of the stub section:
> 
> 
> R0 =0x00000000f001cee8 is an oop: java.util.HashMap 
> {0x00000000f001cee8} - klass: 'java/util/HashMap' - flags: is_cloneable_fast 
>  - ---- fields (total size 5 words):
>  - transient 'keySet' 'Ljava/util/Set;' @8  null (0x00000000)
>  - transient 'values' 'Ljava/util/Collection;' @12  null (0x00000000)
>  - transient 'table' '[Ljava/util/HashMap$Node;' @16  a 'java/util/HashMap$Node'[128] {0x00000000f001cf10} (0xf001cf10)
>  - transient 'entrySet' 'Ljava/util/Set;' @20  null (0x00000000)
>  - transient 'size' 'I' @24  60 (0x0000003c)
>  - transient 'modCount' 'I' @28  60 (0x0000003c)
>  - 'threshold' 'I' @32  96 (0x00000060)
>  - final 'loadFactor' 'F' @36  0.750000 (0x3f400000)
> R1 =0x0000001fd503201f is an unknown value
> R2 =0x0000f7cf03c5fffc is at entry_point+276 in (nmethod*)0x0000f7cf03c5fdc8
> Compiled method (c1) 5966 2946       1       java.util.HashMap::values (25 bytes)
>  total in heap  [0x0000f7cf03c5fdc8,0x0000f7cf03c60000] = 568
>  main code      [0x0000f7cf03c5fec0,0x0000f7cf03c5ffd0] = 272
>  stub code      [0x0000f7cf03c5ffd0,0x0000f7cf03c60000] = 48
>  mutable data [0x0000f7ced888a580,0x0000f7ced888a5c0] = 64
>  relocation     [0x0000f7ced888a580,0x0000f7ced888a5b0] = 48
>  metadata       [0x0000f7ced888a5b0,0x0000f7ced888a5c0] = 16
>  immutable data [0x0000f7ced888a500,0x0000f7ced888a578] = 120
>  dependencies   [0x0000f7ced888a500,0x0000f7ced888a508] = 8
>  scopes pcs     [0x0000f7ced888a508,0x0000f7ced888a558] = 80
>  scopes data    [0x0000f7ced888a558,0x0000f7ced888a570] = 24
>  speculations   [0x0000f7ced888a570,0x0000f7ced888a574] = 4
> 0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
> --------------------------------------------------------------------------------
>   0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
>   0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8
> --------------------------------------------------------------------------------
> R3 =0x0000f7cf03817578 points into unknown readable ...

Thank you for the reviews and help with testing, @TheRealMDoerr, @adinn.

Apologies for the delayed response - it is due to being out of office. I'm planning to resume work on this PR from tomorrow.

I believe the specific issue revealed in the failed test is due to the `NativePostCallNop::check` is trying to read both NOP and MOVK in a combined 8-byte read, which requires at least two instructions after the perceived call site to be readable. In this case, the deoptimization handler stub code has only one valid instruction after the entry point. As the stub code is positioned right at the end of a page, presumably with the next page not mapped, the combined read fails. A possible solution to this would be to check for NOP only as the first step, and to check for MOVK conditionally.

This issue appears to be potentially independent from the `far_jump` being used instead of `far_call`.

I am planning to spend some time figuring out why tests on my side didn't catch the issue with `far_jump` used instead of `far_call`, and on preparing a test that would deterministically detect the issue with stub code positioned right before an unmapped page.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3426020854

From dbriemann at openjdk.org  Tue Oct 21 12:57:59 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Tue, 21 Oct 2025 12:57:59 GMT
Subject: RFR: 8370240: [PPC64] jhsdb jstack cannot handle continuation stub
 [v2]
In-Reply-To: <RNsAORNRumBhAue6o6Ao4xhlmxc2bOMzHgbqkCFWkTM=.22446acc-b7cc-4bd1-b09c-96d1abc4b3ad@github.com>
References: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
 <RNsAORNRumBhAue6o6Ao4xhlmxc2bOMzHgbqkCFWkTM=.22446acc-b7cc-4bd1-b09c-96d1abc4b3ad@github.com>
Message-ID: <JubRdfKbM0V3ixZBqd8pELHo-NsI1t6wpIsf0xIsGIM=.4f3eb459-ddbb-4f21-8d3c-28c5c3a50fbe@github.com>

On Tue, 21 Oct 2025 09:07:30 GMT, David Briemann <dbriemann at openjdk.org> wrote:

>> This is a port of 8369505 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
>> It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.
>
> David Briemann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unnecessary requires

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27902#issuecomment-3426471466

From dbriemann at openjdk.org  Tue Oct 21 12:58:01 2025
From: dbriemann at openjdk.org (David Briemann)
Date: Tue, 21 Oct 2025 12:58:01 GMT
Subject: Integrated: 8370240: [PPC64] jhsdb jstack cannot handle continuation
 stub
In-Reply-To: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
References: <1VA8MpCMPo-flthS7fbqsaZnSrgsMS5cmr_3NTj8AX8=.4cf813fd-9e6f-4994-8ffa-fb4db7223057@github.com>
Message-ID: <t6DZ93LEfiiqvbqaJr8Nb3nfRHcyky13au-b-p32H3k=.90f68589-ab2f-49e1-b76b-7b9e2375c98c@github.com>

On Mon, 20 Oct 2025 14:56:32 GMT, David Briemann <dbriemann at openjdk.org> wrote:

> This is a port of 8369505 for PPC. It allows to calculate caller SP from `CodeBlob` for continuation stub.
> It also enables the test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackWithVirtualThread.java` for PPC.

This pull request has now been integrated.

Changeset: d4c02397
Author:    David Briemann <dbriemann at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4c023974685148844401688327b2de18b82a994
Stats:     17 lines in 2 files changed: 15 ins; 1 del; 1 mod

8370240: [PPC64] jhsdb jstack cannot handle continuation stub

Reviewed-by: mdoerr, rrich

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

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

From eosterlund at openjdk.org  Tue Oct 21 13:06:43 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 13:06:43 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v6]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <L3FEXk8-Ucj9rQfe6kE1mwN-7jgRCc2VwKMTacbyBQA=.605b424f-9e72-4576-8bbd-e8170ef568b1@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with two additional commits since the last revision:

 - Clean up VMProps
 - Make AOTStreamableObjects diagnostic

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/f7b9f32a..d0b42dfc

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

  Stats: 40 lines in 4 files changed: 2 ins; 28 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

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

From alanb at openjdk.org  Tue Oct 21 13:12:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Oct 2025 13:12:57 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
 <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>
Message-ID: <DSVgFKaNd2rNZ9tMNzCo2eGP3nz1YEJRV__1IuPSiGc=.8b7a6da1-cb55-4f73-80a0-320c9bdfc935@github.com>

On Mon, 20 Oct 2025 10:26:44 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Right, there will be a deadlock if `GetTotalGCCpuTime` is called in the callbacks for events `GarbageCollectionStart`, `GarbageCollectionFinish`

The GarbageCollectionStart and GarbageCollectionFinish events are specified to sent when the VM is "stopped" (VM agnostic wording). The only JVMTI functions specified to be allowed are the raw monitor and the env local storage functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3426554971

From alanb at openjdk.org  Tue Oct 21 13:26:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Oct 2025 13:26:34 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
Message-ID: <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>

On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Certainly, thanks for asking. Researchers in GC are using the GC start/end events (https://dl.acm.org/doi/10.1145/3669940.3707217, https://ieeexplore.ieee.org/document/9804613, https://dl.acm.org/doi/10.1145/3764118, https://dl.acm.org/doi/10.1145/3652024.3665510 etc.) to understand various costs pertaining to GC. I believe one USP of using a JVMTI agent is that it does not require modification of the benchmarking code and allows usage of powerful features made available by framework such as libpfm.
> 
> So these JVMTI hooks are used to read CPU performance counters to get some estimations of various metrics, be it CPU time, cache-misses etc. However this imposes severe limitations especially when it comes GCs with concurrent parts. This patch will expand the capabilities for these users using JVMTI agents to profile applications.

I've no doubt that it is useful but it also reasonable to ask if JVMTI is the right API for monitoring GC in 2025. This is a neglected area, the existing events date from 20 years ago, and pre-date concurrent collectors and other advancements. Is this the start of a revival of JVMTI for profiling tools?  If we could start again what features would a GC monitor interface have to help troubleshooting, performance monitoring, and research? Would we confident modelling a VM and GC agnostic interface or would there be aspects that are very GC specific?

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3426635449

From adinn at openjdk.org  Tue Oct 21 13:59:31 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 21 Oct 2025 13:59:31 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
Message-ID: <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>

On Tue, 21 Oct 2025 11:12:45 GMT, Ruben <duke at openjdk.org> wrote:

> I believe the specific issue revealed in the failed test is due to the NativePostCallNop::check is trying to read both NOP and MOVK in a combined 8-byte read, which requires at least two instructions after the perceived call site to be readable. In this case, the deoptimization handler stub code has only one valid instruction after the entry point. As the stub code is positioned right at the end of a page, presumably with the next page not mapped, the combined read fails. A possible solution to this would be to check for NOP only as the first step, and to check for MOVK conditionally.
> 
> This issue appears to be potentially independent from the far_jump being used instead of far_call.

You may well be correct in your assumption that the error is happening in `NativePostCallNop::check()`. I believe the check for in deopt may well do that. However, the `check()` method does not do a combined 8 byte read. What it does is a 4 byte read at the supplied pc (i.e one instruction's worth of data) to test whether those bytes encode a `nop` instruction. As the comment in the check method makes clear there is no need to test for a following `movz` because the JIT never generates a `bl; nop` or `brl; nop` that is not then followed by a `movz`.

The problem in this error case appears to be that the pc address being tested is `0x0000f7cf03c60000` which is indeed just off the end of the mapped heap, 2 words beyond the branch instruction that took us into the deopt handling code. That would indicate that this value somehow got installed into the link register `lr`. Now this register would have been written with `0x0000f7cf03c5fffc` if the C1 code had used `far_call`. Since we got to the check via a `far_jump` unfortunately `lr` did not get updated with the expected return address. It may be that `0x0000f7cf03c60000` ended up there by chance because `lr` was being used by the JITted code as a data register (that can happen).

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3426822695

From krk at openjdk.org  Tue Oct 21 14:56:43 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 21 Oct 2025 14:56:43 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v3]
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <s0j3Npj89TsuxlrABWYnkSnw-LgZBw8jx6ci8bTwArU=.6eeb4d52-84c3-4a59-b050-55b005c56f2f@github.com>

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - run RotateLeftNode*IdealizationTests on amd64 too
 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - Clean up Hotspot SA after 32-bit x86 removal

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

Changes: https://git.openjdk.org/jdk/pull/27844/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27844&range=02
  Stats: 2781 lines in 47 files changed: 623 ins; 2110 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/27844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27844/head:pull/27844

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

From krk at openjdk.org  Tue Oct 21 14:56:45 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 21 Oct 2025 14:56:45 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]
In-Reply-To: <6YqJmhccFDBabVIQpN3nNt_Cpa1zNQg3rRvtiTCEJmo=.c3653095-8ae3-4f0d-8c3b-50d4109b4b69@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
 <z0iqU4MgsvUh_B4IsEWwArMkz7h9aKKZ5RVJDbKPLKQ=.7ddc6d45-7ed8-4d54-a3a2-dbe997911bd7@github.com>
 <6YqJmhccFDBabVIQpN3nNt_Cpa1zNQg3rRvtiTCEJmo=.c3653095-8ae3-4f0d-8c3b-50d4109b4b69@github.com>
Message-ID: <W4pJdjzfHtQk5Gr5vzDPNpkVj01AgrAOhFjXmq5EMkg=.19d821ef-d4eb-4372-9b82-e5f244e3417d@github.com>

On Fri, 17 Oct 2025 01:11:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/jdk.hotspot.agent/doc/clhsdb.html line 35:
>> 
>>> 33:   classes <font color="red">print all loaded Java classes with Klass*</font>
>>> 34:   detach <font color="red">detach SA from current target</font>
>>> 35:   dis address [ length ]  <font color="red">disassemble (amd64) specified number of instructions from given address</font>
>> 
>> Two issues here. The first is I think this was previously incorrect in that SA supports any architecture for which it can find the hsdis library. You can probably just drop the amd64 reference or add "requires hsdis".
>> 
>> The 2nd issue is with amd64 vs x86_64. It seems in SA the two basically have the same meaning, and you see a lot of C code that checks for both. However, the java code seems to always just reference AMD64 (but also works with x86_64). I'm just wondering if this is consistent with the rest of hotspot, or if we should consider a rename to x86_64 instead of amd64.
>> 
>> BTW, at the platform level there are some amd64 vs x86_64 differences. The one I noted is that MacOSX is considered x86_64 and I think linux and windows are amd64. I'm not sure why, but I recently noted a test that had an @requires for `os.arch == "amd64"` and that kept is from running on macosx-x64 until the @requires was expanded to also allow for `os.arch == "x86_64"`.  You should take extra care to make sure that these changes work with all the x86_64, including macosx. I see some places in the C code where we check for both amd64 and x86_64 and some where we only check for amd64. Perhaps x86_64 is not used by SA for macosx.
>
> AMD64 is historical, it should all be changed to x86_64. The only place AMD64 is relevant is in actual AMD processor specific code.

Thanks for the reviews. 

I have updated the html to read "requires hsdis".

Regarding checking for `amd64` vs. `x86_64`, I found two cases where one of `x86_64` and `amd64` is checked but not the other:


test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeLongIdealizationTests.java
34: * @requires os.arch == "x86_64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")

test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeIntIdealizationTests.java
34: * @requires os.arch == "x86_64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")


I checked the C++ sources for `RotateLeftNode::Value` and `RotateLeftNode::Ideal`, I couldn't find any platform-specific logic that would justify excluding `amd64`. I have updated both tests to include `amd64` in their `@requires`.

Is there a specific `x86_64` vs. `amd64` check in C you would like to point out?

For the total annihilation of the `amd64` naming, I have cut an issue at [JDK-8370339](https://bugs.openjdk.org/browse/JDK-8370339).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2448649698

From eosterlund at openjdk.org  Tue Oct 21 15:16:06 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 15:16:06 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Change streaming/mapping states to be binary instead of tri states

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/d0b42dfc..70fb7acc

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

  Stats: 240 lines in 24 files changed: 105 ins; 87 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

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

From krk at openjdk.org  Tue Oct 21 15:19:35 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 21 Oct 2025 15:19:35 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v4]
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <kD2y2tGhPWQZAvWuYUPMICTuhQoKvVBHjjRbzNrQJt0=.3556b1cc-7895-4053-9e88-7d8e2eecf879@github.com>

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:

  requires hsdis

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27844/files
  - new: https://git.openjdk.org/jdk/pull/27844/files/1011b304..f6387b57

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

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

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

From eosterlund at openjdk.org  Tue Oct 21 15:20:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 15:20:27 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
Message-ID: <Jrqk8NmgvIbXGHjFR-HHlMRBdOMdpDJxty4NBlm61S8=.71b10538-fd36-4d1a-8245-08f4f13d7320@github.com>

On Tue, 21 Oct 2025 15:16:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change streaming/mapping states to be binary instead of tri states

We discussed that the AOTStreamableObjects should be a diagnostic JVM option. There isn't really a good reason for users to fiddle with it, but is there as a diagnostic thing. So I made that change.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3427217293

From eosterlund at openjdk.org  Tue Oct 21 15:20:32 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 21 Oct 2025 15:20:32 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v3]
In-Reply-To: <jUyva7bG0i9CIhDRa_ohAHYwFXCWrGUKOhzqURYbNRs=.cca0ef3c-06e1-44a4-98c3-f7095cdfcc41@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <Zcf3DXx5UnaHPis6U4WcRP7ROh8YVGF83w3EO5-JQEM=.2bba40fa-68ed-4f77-9835-4aca667af3f8@github.com>
 <j1eNFqsirL4dc2NnKffL6JeHfwu9Vfbz18lNKDRE8Ww=.2b0c9d0e-b8e4-46dd-9e1a-ffed593fa5db@github.com>
 <tvNUchlujyuFXlPfDt758DGst7XK1V9hA5kkoFxScS4=.867819a8-fd43-417a-aebe-4186259c791b@github.com>
 <jUyva7bG0i9CIhDRa_ohAHYwFXCWrGUKOhzqURYbNRs=.cca0ef3c-06e1-44a4-98c3-f7095cdfcc41@github.com>
Message-ID: <i5kBskWAAQEYzTPv_i90PiMpoDV0Pd3_6Gw6q49uqXI=.2944dd5a-c3be-48be-bbc0-bb0628e0ff5d@github.com>

On Mon, 20 Oct 2025 21:36:54 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Okay. @stefank is having a look at fixing this.
>
> I've sort-of implemented the second part of your comment about removing the tri-state:
> https://github.com/fisk/jdk/compare/8326035_JEP_object_streaming_v6...stefank:jdk:8326035_JEP_object_streaming_v6_stefank
> 
> The enum had *four* states (`uninitialized`, `mapping`, `streaming`, `none`) and while reading this PR the `none` part seemed unusual. After working on the proposed patch I think the `none` value served a purpose, but let's see if a patch without it makes sense.
> 
> The patch still uses an enum instead of two booleans. I think that makes the code more readable because we encode the three states with three enum values. If we were to use two booleans we would end up with four possible states and then the reader of the code would have to figure out which of the forth state is an invalid state. I think what we have in the patch above is safer. (Let's revisit this if this still is a blocker)
> 
> So, I removed `none` and added strict asserts that you are not allowed to ask for the mode until the variable has transitioned away from `uninitialized` to either `mapping` or `streaming`. After the variable has been initialized the questions are binary and you have `is_loading_mapping_mode() == !is_loading_streaming_mode()`. I don't see the appeal to remove one of these two functions, because that just adds negation to the code and that makes it harder to read. (We can experiment with that in a separate patch)
> 
> I tried to take it even further and join these `is_loading` functions with the `is_archived_heap_in_use` and the `is_in_use` properties, but that hit problems with error-edge cases. I have a feeling that the `none` value dealt with these problems.
> 
> Some more details about the edge-case problems:
> 
> During loading of the heap archive there is a duration where we have decided that we are going to load the archived heap and what loading mode to use, but the archive has not been loaded enough have the `is_archived_heap_in_use` function return `true`. During these early stages we must use the `is_loading` and `is_loading_` functions. After `is_archived_heap_in_use` starts to return the correct value, the code likely needs to use that function instead of the `is_loading` functions. Some parts of the AOT/CDS code will bug out if you try to use the `is_loading` functions after an error.
> 
> So, I've tried to keep the usages of `is_loading` functions inside AOT/CDS code. The `is_archived_heap_in_use`, or one of it's sub-components (E.g. `AOTMappedHeapLoader:is_in_use()`), are...

Thank you for the contribution, @stefank. I added it to the PR. @iklam hope this addresses your concerns.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27732#discussion_r2448732105

From phubner at openjdk.org  Tue Oct 21 16:43:50 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Tue, 21 Oct 2025 16:43:50 GMT
Subject: RFR: 8365896: Remove unnecessary explicit buffer nul-termination after
 using os::snprintf
Message-ID: <vgtsrZK2bRhGJ_69iR-tVtzTYI5ciFAuX-9yIo4nVbk=.e6f0daf5-e3ef-4af8-b3c7-65881d33b506@github.com>

Hi all,

This PR removes some leftover null terminators and buffer reservations for null terminators, which have been made redundant with the new `snprintf` family of functions. 

In order to find these occurrences, I methodologically used multiple regular expressions over the entire codebase. I took a look at around 130 files in total, and updated where appropriate. 

I?ve tested this through tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64) and Windows (x64). I?ve also successfully compiled for PowerPC and Zero on Linux.

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

Commit messages:
 - Remove unneccessary null terminator reservations.
 - Remove redundant null termination.

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

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

From sspitsyn at openjdk.org  Tue Oct 21 19:08:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 19:08:48 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
 <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>
Message-ID: <y9wgNd7XViOW43bMP3CEAR5EVv7DVCoABHhvgXXul2o=.d5fbd3cc-5a28-4322-b808-759974d5c1e1@github.com>

On Tue, 21 Oct 2025 13:24:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've no doubt that it is useful but it also reasonable to ask if JVMTI is the right API for monitoring GC in 2025. This is a neglected area, the existing events date from 20 years ago, and pre-date concurrent collectors and other advancements. Is this the start of a revival of JVMTI for profiling tools? If we could start again what features would a GC monitor interface have to help troubleshooting, performance monitoring, and research? Would we confident modelling a VM and GC agnostic interface or would there be aspects that are very GC specific?

Thank you, Alan. There was some offline Slack conversation with Ron and Jonas. Conclusion is the JMX support should be enough for this. So, I've closed the enhancement as WNF and this PR as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3428949447

From sspitsyn at openjdk.org  Tue Oct 21 19:08:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 19:08:49 GMT
Subject: Withdrawn: 8369449: Spec: introduce new JVMTI function
 GetTotalGCCpuTime
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <_ipWevP4P2gHRrOmOncxXrrOXkwa1kn9rvLtKUHKK_Q=.87a85881-c8ea-4321-87f1-67240d06883a@github.com>

On Fri, 17 Oct 2025 21:02:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

This pull request has been closed without being integrated.

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

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

From lmesnik at openjdk.org  Tue Oct 21 20:32:12 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 21 Oct 2025 20:32:12 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v3]
In-Reply-To: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
Message-ID: <d3_ircHB7fILLkbt-moUZl4mEmrIYiSUn-ZeSl3iX5c=.d57b8b94-8fe1-4c90-89d3-ddc98a4f8866@github.com>

> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
> 
> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
> 
> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
> 
> The location should be zero for JNI access.

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

 - completed renaming
 - renamed test
 - updated after feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27584/files
  - new: https://git.openjdk.org/jdk/pull/27584/files/bb5837ec..8662725f

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

  Stats: 74 lines in 4 files changed: 17 ins; 41 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27584/head:pull/27584

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

From amenkov at openjdk.org  Tue Oct 21 21:28:50 2025
From: amenkov at openjdk.org (Alex Menkov)
Date: Tue, 21 Oct 2025 21:28:50 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
Message-ID: <PRjp8AbuSMpbTneAlLJ2pYxbQqLshCDjgGA3SnJWOaM=.039679a9-7525-44bb-ad38-e9122edf289b@github.com>

On Tue, 21 Oct 2025 09:47:52 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

Marked as reviewed by amenkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3362764848

From sspitsyn at openjdk.org  Tue Oct 21 22:53:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 22:53:49 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
Message-ID: <9AoC9cHD7-h1UqvjaMQ-qOVjl1u5NKYG0-Gy2IBbkXg=.f120443e-9d31-43f0-a85d-9b531398fdc8@github.com>

On Tue, 21 Oct 2025 09:47:52 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cc

The fix is good. I've posted a couple of nits though.

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 47:

> 45:  * @run junit TestEarlyDynamicLoad
> 46:  */
> 47: public class TestEarlyDynamicLoad {

Nit: It is convenient if the test folder name matches the test class name. There are several cases where this is broken in our testbase. But it is still a good idea to keep this invariant where possible.

test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 54:

> 52:     fprintf(stderr, "JVMTI error occurred during SetEventNotificationMode\n");
> 53:     return 1;
> 54:   }

Nit: The returned values have to be JNI_ERR or JNI_OK.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3362992561
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2449910819
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2449902636

From sspitsyn at openjdk.org  Tue Oct 21 23:19:46 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 23:19:46 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v3]
In-Reply-To: <d3_ircHB7fILLkbt-moUZl4mEmrIYiSUn-ZeSl3iX5c=.d57b8b94-8fe1-4c90-89d3-ddc98a4f8866@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <d3_ircHB7fILLkbt-moUZl4mEmrIYiSUn-ZeSl3iX5c=.d57b8b94-8fe1-4c90-89d3-ddc98a4f8866@github.com>
Message-ID: <mmalGEIGvQb1J7Rylt8Q91euQc_Z_wcN8a7X3gu-5gY=.bfa47626-0e79-4b6b-8981-bea738f644d8@github.com>

On Tue, 21 Oct 2025 20:32:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
>> 
>> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
>> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
>> 
>> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
>> 
>> The location should be zero for JNI access.
>
> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - completed renaming
>  - renamed test
>  - updated after feedback

Thank you for the update! It looks pretty good to me.
I've posted several more suggestions though.

src/hotspot/share/prims/jvmtiExport.cpp line 2283:

> 2281:   // In this case the frame is only marked for deoptimization but still remains compiled.
> 2282:   // Also, the last frame might be compiled if events were not enabled for
> 2283:   // this thread. The thread filtering is done later.

Q: The following part of comment is confusing: `" ... if events were not enabled for this thread."
     How do we post the events if they were not enabled? Do I miss anything?

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/FieldsEventsFromJNI.java line 30:

> 28:  * @run main/othervm/native -agentlib:JvmtiFieldEventsFromJNI FieldsEventsFromJNI
> 29:  */
> 30: public class FieldsEventsFromJNI {

Nit: The class name still does not match the test folder name: `s/FieldsEventsFromJNI/FieldEventsFromJNI/g`

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 44:

> 42:   }
> 43:   deallocate(jvmti,jni, m_name);
> 44: 

Nit: Still unneeded empty line. :)

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 167:

> 165: }
> 166: 
> 167: 

Nit: Still unneeded empty line. :)

test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 333:

> 331:   jvmtiError err = jvmti->GetFieldName(field_class, field, &name, &signature, nullptr);
> 332:   check_jvmti_status(jni, err, "get_field_name: error in JVMTI GetFieldName call");
> 333:   deallocate(jvmti, jni, signature);

Nit: Sorry, I've not noticed that the signature is not really needed. Then `nullptr` can be passed instead of `&signature` as well.

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

PR Review: https://git.openjdk.org/jdk/pull/27584#pullrequestreview-3363022782
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2449945745
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2449929078
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2449926090
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2449926933
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2449924748

From kdnilsen at openjdk.org  Tue Oct 21 23:42:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 21 Oct 2025 23:42:49 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v27]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <4qrP0qDQkfL-ogpd0AQ2gJMMlnvo80IQJ36aQHYbTDo=.790fee9b-1720-4aab-bde2-e4ff205426d0@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Fix up vmstructs and other infrastructure for jmap heap dump

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/891e96b8..ee617c30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=25-26

  Stats: 130 lines in 5 files changed: 63 ins; 59 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

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

From dholmes at openjdk.org  Wed Oct 22 02:00:02 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:00:02 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]
In-Reply-To: <W4pJdjzfHtQk5Gr5vzDPNpkVj01AgrAOhFjXmq5EMkg=.19d821ef-d4eb-4372-9b82-e5f244e3417d@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
 <z0iqU4MgsvUh_B4IsEWwArMkz7h9aKKZ5RVJDbKPLKQ=.7ddc6d45-7ed8-4d54-a3a2-dbe997911bd7@github.com>
 <6YqJmhccFDBabVIQpN3nNt_Cpa1zNQg3rRvtiTCEJmo=.c3653095-8ae3-4f0d-8c3b-50d4109b4b69@github.com>
 <W4pJdjzfHtQk5Gr5vzDPNpkVj01AgrAOhFjXmq5EMkg=.19d821ef-d4eb-4372-9b82-e5f244e3417d@github.com>
Message-ID: <0kOVT0jKO7wshPvx-AbDL0MGtSaCUSGJi6WIHgqrGdM=.c3be17fe-6614-44b4-b185-1f5a2715187b@github.com>

On Tue, 21 Oct 2025 14:51:41 GMT, Kerem Kat <krk at openjdk.org> wrote:

> For the total annihilation of the amd64 naming, I have cut an issue at [JDK-8370339](https://bugs.openjdk.org/browse/JDK-8370339).

I meant this for the SA code, not the JDK in its entirety. For historical reasons we still define os.arch as "amd64" on Linux and Windows. We need to fix tests that are using the wrong `@requires` values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2450181801

From dholmes at openjdk.org  Wed Oct 22 02:22:04 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:22:04 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v2]
In-Reply-To: <0kOVT0jKO7wshPvx-AbDL0MGtSaCUSGJi6WIHgqrGdM=.c3be17fe-6614-44b4-b185-1f5a2715187b@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <Xwze9zPK1xL_fyPBeAAFokt80Pa_JHnJNFnR8xqS2n8=.a6d73cb8-a198-44fc-bf96-7ef9347012ff@github.com>
 <z0iqU4MgsvUh_B4IsEWwArMkz7h9aKKZ5RVJDbKPLKQ=.7ddc6d45-7ed8-4d54-a3a2-dbe997911bd7@github.com>
 <6YqJmhccFDBabVIQpN3nNt_Cpa1zNQg3rRvtiTCEJmo=.c3653095-8ae3-4f0d-8c3b-50d4109b4b69@github.com>
 <W4pJdjzfHtQk5Gr5vzDPNpkVj01AgrAOhFjXmq5EMkg=.19d821ef-d4eb-4372-9b82-e5f244e3417d@github.com>
 <0kOVT0jKO7wshPvx-AbDL0MGtSaCUSGJi6WIHgqrGdM=.c3be17fe-6614-44b4-b185-1f5a2715187b@github.com>
Message-ID: <M4Uv-C5QbA_XN_tveBOjcC1Y3HMWAYDF1OoXnqaTSsk=.6343120e-419a-47f1-9e2f-61e2c7037a50@github.com>

On Wed, 22 Oct 2025 01:57:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks for the reviews. 
>> 
>> I have updated the html to read "requires hsdis".
>> 
>> Regarding checking for `amd64` vs. `x86_64`, I found two cases where one of `x86_64` and `amd64` is checked but not the other:
>> 
>> 
>> test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeLongIdealizationTests.java
>> 34: * @requires os.arch == "x86_64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")
>> 
>> test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeIntIdealizationTests.java
>> 34: * @requires os.arch == "x86_64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")
>> 
>> 
>> I checked the C++ sources for `RotateLeftNode::Value` and `RotateLeftNode::Ideal`, I couldn't find any platform-specific logic that would justify excluding `amd64`. I have updated both tests to include `amd64` in their `@requires`.
>> 
>> Is there a specific `x86_64` vs. `amd64` check in C you would like to point out?
>> 
>> For the total annihilation of the `amd64` naming, I have cut an issue at [JDK-8370339](https://bugs.openjdk.org/browse/JDK-8370339).
>
>> For the total annihilation of the amd64 naming, I have cut an issue at [JDK-8370339](https://bugs.openjdk.org/browse/JDK-8370339).
> 
> I meant this for the SA code, not the JDK in its entirety. For historical reasons we still define os.arch as "amd64" on Linux and Windows. We need to fix tests that are using the wrong `@requires` values.

I filed https://bugs.openjdk.org/browse/JDK-8370378 for 3 compiler tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2450222785

From dholmes at openjdk.org  Wed Oct 22 02:22:11 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:22:11 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v4]
In-Reply-To: <kD2y2tGhPWQZAvWuYUPMICTuhQoKvVBHjjRbzNrQJt0=.3556b1cc-7895-4053-9e88-7d8e2eecf879@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <kD2y2tGhPWQZAvWuYUPMICTuhQoKvVBHjjRbzNrQJt0=.3556b1cc-7895-4053-9e88-7d8e2eecf879@github.com>
Message-ID: <btu_jPlDr79cKhdoQXTu3JF5i2Om3ldsLBEP74kxLJY=.33926440-a42e-4dbb-8b9f-554b03fc7369@github.com>

On Tue, 21 Oct 2025 15:19:35 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requires hsdis

test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeIntIdealizationTests.java line 34:

> 32:  * @library /test/lib /
> 33:  * @run driver compiler.c2.irTests.RotateLeftNodeIntIdealizationTests
> 34:  * @requires os.arch == "x86_64" | os.arch == "amd64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")

Do not fix this as part of this PR as it is unrelated.

test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeLongIdealizationTests.java line 34:

> 32:  * @library /test/lib /
> 33:  * @run driver compiler.c2.irTests.RotateLeftNodeLongIdealizationTests
> 34:  * @requires os.arch == "x86_64" | os.arch == "amd64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")

Do not fix this as part of this PR as it is unrelated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2450225977
PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2450226326

From dholmes at openjdk.org  Wed Oct 22 02:55:01 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 22 Oct 2025 02:55:01 GMT
Subject: RFR: 8365896: Remove unnecessary explicit buffer nul-termination
 after using os::snprintf
In-Reply-To: <vgtsrZK2bRhGJ_69iR-tVtzTYI5ciFAuX-9yIo4nVbk=.e6f0daf5-e3ef-4af8-b3c7-65881d33b506@github.com>
References: <vgtsrZK2bRhGJ_69iR-tVtzTYI5ciFAuX-9yIo4nVbk=.e6f0daf5-e3ef-4af8-b3c7-65881d33b506@github.com>
Message-ID: <v9Tbe4vIJvgWOTo_EC-0AjDsjizdSEm5LZA_iAtAH9U=.5bd42eaa-1570-4b1e-8324-993aa682278c@github.com>

On Tue, 21 Oct 2025 16:05:31 GMT, Paul H?bner <phubner at openjdk.org> wrote:

> Hi all,
> 
> This PR removes some leftover null terminators and buffer reservations for null terminators, which have been made redundant with the new `snprintf` family of functions. 
> 
> In order to find these occurrences, I methodologically used multiple regular expressions over the entire codebase. I took a look at around 130 files in total, and updated where appropriate. 
> 
> I?ve tested this through tiers 1-5 on Linux (x64, AArch64), macOS (x64, AArch64) and Windows (x64). I?ve also successfully compiled for PowerPC and Zero on Linux.

They all seem fine to me. Thanks for doing this cleanup.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27920#pullrequestreview-3363518323

From lmesnik at openjdk.org  Wed Oct 22 03:39:57 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 03:39:57 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v4]
In-Reply-To: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
Message-ID: <thYRKBT3wWWLG6Gk-eAH_h2KklPO70EOunOxhHWrGT4=.cf183b80-a19f-4e44-8583-24d72a986702@github.com>

> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
> 
> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
> 
> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
> 
> The location should be zero for JNI access.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27584/files
  - new: https://git.openjdk.org/jdk/pull/27584/files/8662725f..b737d9ea

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

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

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

From lmesnik at openjdk.org  Wed Oct 22 03:40:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 03:40:02 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v2]
In-Reply-To: <yN4RBa1BoiF6Qsm0lxXvG1K6WF01XV2ijodkahvMscA=.759aef17-3d36-4e2f-a75e-f7e02446a5b9@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <jLcTWqm4cz7c863ysJVqjbdiaQlERnpJZHHB3F4AECo=.04631781-37ff-49d8-a206-78b4c15a414a@github.com>
 <yN4RBa1BoiF6Qsm0lxXvG1K6WF01XV2ijodkahvMscA=.759aef17-3d36-4e2f-a75e-f7e02446a5b9@github.com>
Message-ID: <Pi-e5qTSyha4n7hu8vn-75RwRiDquWBUPnIWDHuOFOE=.a4c533a3-83c2-492a-bd29-02532473ae8c@github.com>

On Tue, 21 Oct 2025 07:35:42 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comment
>
> src/hotspot/share/prims/jvmtiExport.cpp line 2226:
> 
>> 2224:     javaVFrame *jvf = thread->last_java_vframe(&reg_map);
>> 2225:     method = jvf->method();
>> 2226:     address = jvf->method()->code_base();
> 
> Nit: I'm thinking if this code can be simplified a little bit if the same approach with `reg_map` can be used for interpreter frame as well.

Thanks for suggestion, yes it works. The same approach might be used for compiler/interpreter frame.

> test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/TestFieldsEventsFromJNI.java line 29:
> 
>> 27:  * @bug 8224852
>> 28:  * @run main/othervm/native -agentlib:JvmtiFieldEventsFromJNI TestFieldsEventsFromJNI
>> 29:  * @run main/othervm/native -agentlib:JvmtiFieldEventsFromJNI -Xcomp TestFieldsEventsFromJNI
> 
> Nit: It is convenient when the test folder and the Java file have the same name. Many tests in the `serviceability/jvmti` folder follow this rule. So, I'd suggest to get rid of the `Test` prefix in this class name. An additional advantage would be that the class name is shorter. :)

We have all 3 different patterns:

jvmtiFieldEventsFromJNI/TestvmtiFieldEventsFromJNI.java
jvmtiFieldEventsFromJNI/jvmtiFieldEventsFromJNI.java
jvmtiFieldEventsFromJNI/jvmtiFieldEventsFromJNITest.java

and somtimes

jvmtiFieldEventsFromJNITest.java
TestvmtiFieldEventsFromJNI.java

while 
`jvmtiFieldEventsFromJNI/`
 directory contains native path only.

The 'Test' prefix or suffix useful to quickly find test entry if it has more then on java file.

Do we want to use this convention for serviceability/jvmti tests?

jvmtiFieldEventsFromJNI/
jvmtiFieldEventsFromJNI/jvmtiFieldEventsFromJNI.java
jvmtiFieldEventsFromJNI/libJvmtiFieldEventsFromJNI.jcpp



If there are no objections, I'll rename the test.

> test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 43:
> 
>> 41:   jni->DeleteLocalRef(object_class);
>> 42:   return obj_class_name;
>> 43: }
> 
> Nit: Would it be good to add this into `jvmti_common.hpp`?

Done.

> test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 102:
> 
>> 100:   deallocate(jvmti,jni, f_name);
>> 101: 
>> 102: 
> 
> Nit: Unneeded empty lines: 68, 102 and 137.

done

> test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/FieldsEventsFromJNI.java line 48:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Nit: Is this really needed? In fact, we have it in many tests though.

Yes, it is needed for tests that have native methods to communicate with agent. This test has:

    private native void enableEventsAndAccessField(boolean isEventExpected, Thread eventThread);
    private native void enableEventsAndModifyField(boolean isEventExpected, Thread eventThread);

> test/lib/jdk/test/lib/jvmti/jvmti_common.hpp line 335:
> 
>> 333:   check_jvmti_status(jni, err, "get_field_name: error in JVMTI GetFieldName call");
>> 334:   deallocate(jvmti,jni, signature);
>> 335:   deallocate(jvmti,jni, generic);
> 
> Nit: The lines 334 and 335 miss space after comma in the argument lists. Also, it is better to pass `nullptr` instead of `&generic`, so there would not be need to have this local and to deallocate the returned string.

Thanks, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2448930076
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2448918343
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2448924000
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2448925404
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2448922851
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2448926538

From lmesnik at openjdk.org  Wed Oct 22 03:40:06 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 03:40:06 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v3]
In-Reply-To: <mmalGEIGvQb1J7Rylt8Q91euQc_Z_wcN8a7X3gu-5gY=.bfa47626-0e79-4b6b-8981-bea738f644d8@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <d3_ircHB7fILLkbt-moUZl4mEmrIYiSUn-ZeSl3iX5c=.d57b8b94-8fe1-4c90-89d3-ddc98a4f8866@github.com>
 <mmalGEIGvQb1J7Rylt8Q91euQc_Z_wcN8a7X3gu-5gY=.bfa47626-0e79-4b6b-8981-bea738f644d8@github.com>
Message-ID: <V5CPsxFtkqtC5fA5k5pW65kPeRQo6-JbIRuZLjBolGM=.fc0b790d-04ba-437c-912c-2026c5701a90@github.com>

On Tue, 21 Oct 2025 23:15:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - completed renaming
>>  - renamed test
>>  - updated after feedback
>
> src/hotspot/share/prims/jvmtiExport.cpp line 2283:
> 
>> 2281:   // In this case the frame is only marked for deoptimization but still remains compiled.
>> 2282:   // Also, the last frame might be compiled if events were not enabled for
>> 2283:   // this thread. The thread filtering is done later.
> 
> Q: The following part of comment is confusing: `" ... if events were not enabled for this thread."
>      How do we post the events if they were not enabled? Do I miss anything?

Yes
The
jni_GetField_probe
is called on every field if any of fields access event is envabled.

  /* Keep JVMTI addition small and only check enabled flag here.       */ \
  if (JvmtiExport::should_post_field_access()) { \
    o = JvmtiExport::jni_GetField_probe(thread, obj, o, k, fieldID, false); \
  } \

The jni_GetField_probe checks if the events are enabled for this specific field on any thread for any jvmtiEnv and call

post_field_access_by_jni

which prepare all the data and call 

post_field_access

Only on this level it is check which threads and environments should post events. I suspect that it is done for unification of jni/non-jni check.

 So ```post_field_access_by_jni```  is executed for threads where events is not enabled.

> test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/FieldsEventsFromJNI.java line 30:
> 
>> (failed to retrieve contents of file, check the PR for context)
> Nit: The class name still does not match the test folder name: `s/FieldsEventsFromJNI/FieldEventsFromJNI/g`

Thanks, missed 's'.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2450316108
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2450317813

From sspitsyn at openjdk.org  Wed Oct 22 04:51:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 04:51:03 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v4]
In-Reply-To: <thYRKBT3wWWLG6Gk-eAH_h2KklPO70EOunOxhHWrGT4=.cf183b80-a19f-4e44-8583-24d72a986702@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <thYRKBT3wWWLG6Gk-eAH_h2KklPO70EOunOxhHWrGT4=.cf183b80-a19f-4e44-8583-24d72a986702@github.com>
Message-ID: <XBv0JgK-q3-5Ip5Qe9udYg6MbqBZjVgGJDbwtWDXLe8=.0d391ea2-db2a-4f70-8df7-867f5b4f45c7@github.com>

On Wed, 22 Oct 2025 03:39:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
>> 
>> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
>> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
>> 
>> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
>> 
>> The location should be zero for JNI access.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 167:

> 165: 
> 166: JNIEXPORT void JNICALL
> 167: Java_FieldsEventsFromJNI_enableEventsAndModifyField(

Need to rename these as well: `s/Java_FieldsEventsFromJNI/Java_FieldEventsFromJNI/g`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2450427318

From sspitsyn at openjdk.org  Wed Oct 22 04:59:03 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 04:59:03 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v4]
In-Reply-To: <XBv0JgK-q3-5Ip5Qe9udYg6MbqBZjVgGJDbwtWDXLe8=.0d391ea2-db2a-4f70-8df7-867f5b4f45c7@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <thYRKBT3wWWLG6Gk-eAH_h2KklPO70EOunOxhHWrGT4=.cf183b80-a19f-4e44-8583-24d72a986702@github.com>
 <XBv0JgK-q3-5Ip5Qe9udYg6MbqBZjVgGJDbwtWDXLe8=.0d391ea2-db2a-4f70-8df7-867f5b4f45c7@github.com>
Message-ID: <j4yTnjEUyuI0MrvHTh3kfFgvoHZw6_0cDLX1RpipiZU=.6cf221a4-5745-4a35-8a21-a65544539b98@github.com>

On Wed, 22 Oct 2025 04:47:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback
>
> test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp line 167:
> 
>> 165: 
>> 166: JNIEXPORT void JNICALL
>> 167: Java_FieldsEventsFromJNI_enableEventsAndModifyField(
> 
> Need to rename these as well: `s/FieldsEventsFromJNI/FieldEventsFromJNI/g`.

> jvmtiFieldEventsFromJNI/
> jvmtiFieldEventsFromJNI/jvmtiFieldEventsFromJNI.java
> jvmtiFieldEventsFromJNI/libJvmtiFieldEventsFromJNI.jcpp

It seems the file names are still not right and do not follow the above patterns:
 - FieldsEventsFromJNI/FieldsEventsFromJNI.java
 - FieldsEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp

To follow the above this needs to be applied to folder and Java file names:
   `s/FieldsEventsFromJNI/FieldEventsFromJNI/g`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2450437918

From lmesnik at openjdk.org  Wed Oct 22 05:06:40 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 05:06:40 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v5]
In-Reply-To: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
Message-ID: <oCfQox4p-5sButQvgNfqd14HOa9vwpe4GZrVkTtN3Vc=.5f53a08c-5fd3-4eb3-b174-1ff9141d4018@github.com>

> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
> 
> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
> 
> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
> 
> The location should be zero for JNI access.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  renamed native path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27584/files
  - new: https://git.openjdk.org/jdk/pull/27584/files/b737d9ea..76226abf

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

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

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

From lmesnik at openjdk.org  Wed Oct 22 05:06:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 05:06:41 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v5]
In-Reply-To: <oCfQox4p-5sButQvgNfqd14HOa9vwpe4GZrVkTtN3Vc=.5f53a08c-5fd3-4eb3-b174-1ff9141d4018@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <oCfQox4p-5sButQvgNfqd14HOa9vwpe4GZrVkTtN3Vc=.5f53a08c-5fd3-4eb3-b174-1ff9141d4018@github.com>
Message-ID: <eIos49-DC4f_nYJob5ZQEZ04o1OU9kMGEdVYepPalao=.05051471-2627-48aa-ae44-b6477fb4dcba@github.com>

On Wed, 22 Oct 2025 05:03:22 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
>> 
>> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
>> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
>> 
>> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
>> 
>> The location should be zero for JNI access.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   renamed native path

I renamed files. Seems that I forgot to push button "review changes" first time. So some of my comments were published later.

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

PR Review: https://git.openjdk.org/jdk/pull/27584#pullrequestreview-3363728522

From sspitsyn at openjdk.org  Wed Oct 22 05:06:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 05:06:42 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v3]
In-Reply-To: <V5CPsxFtkqtC5fA5k5pW65kPeRQo6-JbIRuZLjBolGM=.fc0b790d-04ba-437c-912c-2026c5701a90@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <d3_ircHB7fILLkbt-moUZl4mEmrIYiSUn-ZeSl3iX5c=.d57b8b94-8fe1-4c90-89d3-ddc98a4f8866@github.com>
 <mmalGEIGvQb1J7Rylt8Q91euQc_Z_wcN8a7X3gu-5gY=.bfa47626-0e79-4b6b-8981-bea738f644d8@github.com>
 <V5CPsxFtkqtC5fA5k5pW65kPeRQo6-JbIRuZLjBolGM=.fc0b790d-04ba-437c-912c-2026c5701a90@github.com>
Message-ID: <qMYODDLkOiusrAB4_4Megzlb2zGHveh9RR-LAAHGNx8=.7f936846-cf6e-479a-a2fa-cc34ea78ab29@github.com>

On Wed, 22 Oct 2025 03:28:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> src/hotspot/share/prims/jvmtiExport.cpp line 2283:
>> 
>>> 2281:   // In this case the frame is only marked for deoptimization but still remains compiled.
>>> 2282:   // Also, the last frame might be compiled if events were not enabled for
>>> 2283:   // this thread. The thread filtering is done later.
>> 
>> Q: The following part of comment is confusing: `" ... if events were not enabled for this thread."
>>      How do we post the events if they were not enabled? Do I miss anything?
>
> Yes
> The
> jni_GetField_probe
> is called on every field if any of fields access event is envabled.
> 
>   /* Keep JVMTI addition small and only check enabled flag here.       */ \
>   if (JvmtiExport::should_post_field_access()) { \
>     o = JvmtiExport::jni_GetField_probe(thread, obj, o, k, fieldID, false); \
>   } \
> 
> The jni_GetField_probe checks if the events are enabled for this specific field on any thread for any jvmtiEnv and call
> 
> post_field_access_by_jni
> 
> which prepare all the data and call 
> 
> post_field_access
> 
> Only on this level it is check which threads and environments should post events. I suspect that it is done for unification of jni/non-jni check.
> 
>  So ```post_field_access_by_jni```  is executed for threads where events is not enabled.

I see now, thanks! But then it means the comments are not easy to understand correctly. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2450445678

From lmesnik at openjdk.org  Wed Oct 22 05:06:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 05:06:44 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v4]
In-Reply-To: <j4yTnjEUyuI0MrvHTh3kfFgvoHZw6_0cDLX1RpipiZU=.6cf221a4-5745-4a35-8a21-a65544539b98@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <thYRKBT3wWWLG6Gk-eAH_h2KklPO70EOunOxhHWrGT4=.cf183b80-a19f-4e44-8583-24d72a986702@github.com>
 <XBv0JgK-q3-5Ip5Qe9udYg6MbqBZjVgGJDbwtWDXLe8=.0d391ea2-db2a-4f70-8df7-867f5b4f45c7@github.com>
 <j4yTnjEUyuI0MrvHTh3kfFgvoHZw6_0cDLX1RpipiZU=.6cf221a4-5745-4a35-8a21-a65544539b98@github.com>
Message-ID: <N8wFqP9r6Y82vOf1A-h5BymPzYgbLjLPJ-4Mi0FEjoc=.74b7d05e-b1a3-42ff-a66b-0889b75f096c@github.com>

On Wed, 22 Oct 2025 04:56:01 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/libFieldsEventsFromJNI.cpp line 167:
>> 
>>> (failed to retrieve contents of file, check the PR for context)
>> Need to rename these as well: `s/FieldsEventsFromJNI/FieldEventsFromJNI/g`.
>
>> jvmtiFieldEventsFromJNI/
>> jvmtiFieldEventsFromJNI/jvmtiFieldEventsFromJNI.java
>> jvmtiFieldEventsFromJNI/libJvmtiFieldEventsFromJNI.jcpp
> 
> It seems the file names are still not right and do not follow the above patterns:
>  - FieldsEventsFromJNI/FieldsEventsFromJNI.java
>  - FieldsEventsFromJNI/libJvmtiFieldEventsFromJNI.cpp
> 
> To follow the above this needs to be applied to folder and Java file names:
>    `s/FieldsEventsFromJNI/FieldEventsFromJNI/g`

Renamved tio
FieldsEventsFromJNI/FieldsEventsFromJNI.java
FieldsEventsFromJNI/libFieldsEventsFromJNI.cpp
the 
'libJvmti...." should be just "lib..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2450444580

From lmesnik at openjdk.org  Wed Oct 22 05:28:37 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 05:28:37 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v6]
In-Reply-To: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
Message-ID: <anWMc2hYAP-wUiRwMwBiLfbODelXyb5DcGvOSUkMXJY=.7d2c062b-94f3-4bfc-bdb4-fd66c87df2ab@github.com>

> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
> 
> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
> 
> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
> 
> The location should be zero for JNI access.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  the updated comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27584/files
  - new: https://git.openjdk.org/jdk/pull/27584/files/76226abf..5fd78080

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

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

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

From lmesnik at openjdk.org  Wed Oct 22 05:28:38 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 05:28:38 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v3]
In-Reply-To: <qMYODDLkOiusrAB4_4Megzlb2zGHveh9RR-LAAHGNx8=.7f936846-cf6e-479a-a2fa-cc34ea78ab29@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <d3_ircHB7fILLkbt-moUZl4mEmrIYiSUn-ZeSl3iX5c=.d57b8b94-8fe1-4c90-89d3-ddc98a4f8866@github.com>
 <mmalGEIGvQb1J7Rylt8Q91euQc_Z_wcN8a7X3gu-5gY=.bfa47626-0e79-4b6b-8981-bea738f644d8@github.com>
 <V5CPsxFtkqtC5fA5k5pW65kPeRQo6-JbIRuZLjBolGM=.fc0b790d-04ba-437c-912c-2026c5701a90@github.com>
 <qMYODDLkOiusrAB4_4Megzlb2zGHveh9RR-LAAHGNx8=.7f936846-cf6e-479a-a2fa-cc34ea78ab29@github.com>
Message-ID: <U7OsmoC9pNDlCpUCRl1bGkNTmKN-28SaqntfxqVbt2Y=.d6ecc00a-42ed-401c-bcef-80c193311a4e@github.com>

On Wed, 22 Oct 2025 05:03:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Yes
>> The
>> jni_GetField_probe
>> is called on every field if any of fields access event is envabled.
>> 
>>   /* Keep JVMTI addition small and only check enabled flag here.       */ \
>>   if (JvmtiExport::should_post_field_access()) { \
>>     o = JvmtiExport::jni_GetField_probe(thread, obj, o, k, fieldID, false); \
>>   } \
>> 
>> The jni_GetField_probe checks if the events are enabled for this specific field on any thread for any jvmtiEnv and call
>> 
>> post_field_access_by_jni
>> 
>> which prepare all the data and call 
>> 
>> post_field_access
>> 
>> Only on this level it is check which threads and environments should post events. I suspect that it is done for unification of jni/non-jni check.
>> 
>>  So ```post_field_access_by_jni```  is executed for threads where events is not enabled.
>
> I see now, thanks! But then it means the comments are not easy to understand correctly. :)

I updated comments. Hope they are clearer now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2450469704

From fandreuzzi at openjdk.org  Wed Oct 22 08:41:15 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 08:41:15 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi 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 40 additional commits since the last revision:

 - rename
 - Merge branch 'master' into JDK-8359472
 - return value
 - cc
 - empty stderr
 - jvmti errors
 - indent
 - close
 - rephrase
 - PidJcmdExecutor. unused import. cc
 - ... and 30 more: https://git.openjdk.org/jdk/compare/4ae824a9...1dafec32

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27766/files
  - new: https://git.openjdk.org/jdk/pull/27766/files/ba3dc024..1dafec32

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

  Stats: 28747 lines in 729 files changed: 16521 ins; 8454 del; 3772 mod
  Patch: https://git.openjdk.org/jdk/pull/27766.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27766/head:pull/27766

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

From fandreuzzi at openjdk.org  Wed Oct 22 08:41:20 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 08:41:20 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v16]
In-Reply-To: <9AoC9cHD7-h1UqvjaMQ-qOVjl1u5NKYG0-Gy2IBbkXg=.f120443e-9d31-43f0-a85d-9b531398fdc8@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <gAaxKEKkzZHE4ehZ_ZSi_0pjjVJQlI7ZtmPFhJuEJ5Y=.8dd8c73a-c67e-476f-affe-c8184ff351fa@github.com>
 <9AoC9cHD7-h1UqvjaMQ-qOVjl1u5NKYG0-Gy2IBbkXg=.f120443e-9d31-43f0-a85d-9b531398fdc8@github.com>
Message-ID: <CEspiX_jVCIUKuPGfoVLKm_kikMQSIg3XykoTeXJ4fc=.4f11c250-4ebb-4163-b887-a75e95b4efdd@github.com>

On Tue, 21 Oct 2025 22:49:35 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cc
>
> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/TestEarlyDynamicLoad.java line 47:
> 
>> 45:  * @run junit TestEarlyDynamicLoad
>> 46:  */
>> 47: public class TestEarlyDynamicLoad {
> 
> Nit: It is convenient if the test folder name matches the test class name. There are several cases where this is broken in our testbase. But it is still a good idea to keep this invariant where possible.

Renamed in 1dafec32b57ac557b66dfe91c4bd2964019c9ff1

> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 54:
> 
>> 52:     fprintf(stderr, "JVMTI error occurred during SetEventNotificationMode\n");
>> 53:     return 1;
>> 54:   }
> 
> Nit: The returned values have to be JNI_ERR or JNI_OK.

Fixed in 205967939772764946e3df0e1633d6cec9e7d4a1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2450933247
PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2450933709

From krk at openjdk.org  Wed Oct 22 08:48:47 2025
From: krk at openjdk.org (Kerem Kat)
Date: Wed, 22 Oct 2025 08:48:47 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v5]
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <2fEidZb-lqK9yIMdmSuFndkHzO5dBxILPn9wmrfQqyc=.ad68690c-e3c8-4009-a974-159d6af93664@github.com>

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:

  Revert "run RotateLeftNode*IdealizationTests on amd64 too"
  
  This reverts commit 1011b304f7cb4d195efc9239acd7784053c67cc1.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27844/files
  - new: https://git.openjdk.org/jdk/pull/27844/files/f6387b57..25aecd07

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

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

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

From krk at openjdk.org  Wed Oct 22 08:48:51 2025
From: krk at openjdk.org (Kerem Kat)
Date: Wed, 22 Oct 2025 08:48:51 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v4]
In-Reply-To: <btu_jPlDr79cKhdoQXTu3JF5i2Om3ldsLBEP74kxLJY=.33926440-a42e-4dbb-8b9f-554b03fc7369@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <kD2y2tGhPWQZAvWuYUPMICTuhQoKvVBHjjRbzNrQJt0=.3556b1cc-7895-4053-9e88-7d8e2eecf879@github.com>
 <btu_jPlDr79cKhdoQXTu3JF5i2Om3ldsLBEP74kxLJY=.33926440-a42e-4dbb-8b9f-554b03fc7369@github.com>
Message-ID: <E4sKGXemJCjUP_wzv3uPccweovp2yViJgRatdpq0IJ0=.dff268d9-226a-4906-94e1-18657f1bda85@github.com>

On Wed, 22 Oct 2025 02:19:00 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   requires hsdis
>
> test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeIntIdealizationTests.java line 34:
> 
>> 32:  * @library /test/lib /
>> 33:  * @run driver compiler.c2.irTests.RotateLeftNodeIntIdealizationTests
>> 34:  * @requires os.arch == "x86_64" | os.arch == "amd64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")
> 
> Do not fix this as part of this PR as it is unrelated.

thanks, reverted.

> test/hotspot/jtreg/compiler/c2/irTests/RotateLeftNodeLongIdealizationTests.java line 34:
> 
>> 32:  * @library /test/lib /
>> 33:  * @run driver compiler.c2.irTests.RotateLeftNodeLongIdealizationTests
>> 34:  * @requires os.arch == "x86_64" | os.arch == "amd64" | os.arch == "aarch64" | (os.arch == "riscv64" & vm.cpu.features ~= ".*zbb.*")
> 
> Do not fix this as part of this PR as it is unrelated.

reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2450950475
PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2450950921

From aph at openjdk.org  Wed Oct 22 10:05:09 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Oct 2025 10:05:09 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
Message-ID: <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>

On Tue, 21 Oct 2025 13:56:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> A possible solution to this would be to check for NOP only as the first step, and to check for MOVK conditionally.

SafeFetch was designed specifically for problems like this one.


diff --git a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp
index df5d97c2376..eff84ac195f 100644
--- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp
+++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp
@@ -29,7 +29,7 @@
 #include "asm/assembler.hpp"
 #include "runtime/icache.hpp"
 #include "runtime/os.hpp"
-#include "runtime/os.hpp"
+#include "runtime/safefetch.hpp"
 #if INCLUDE_JVMCI
 #include "jvmci/jvmciExceptions.hpp"
 #endif
@@ -528,7 +528,7 @@ inline NativeLdSt* NativeLdSt_at(address addr) {
 class NativePostCallNop: public NativeInstruction {
 public:
   bool check() const {
-    uint64_t insns = *(uint64_t*)addr_at(0);
+    uint64_t insns = SafeFetchN((intptr_t*)addr_at(0), 0);
     // Check for two instructions: nop; movk zr, xx
     // These instructions only ever appear together in a post-call
     // NOP, so it's unnecessary to check that the third instruction is

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3431497753

From duke at openjdk.org  Wed Oct 22 11:28:34 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 22 Oct 2025 11:28:34 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v5]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/8d83dd97..a188df0b

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

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

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

From adinn at openjdk.org  Wed Oct 22 12:03:14 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Wed, 22 Oct 2025 12:03:14 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
 <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>
Message-ID: <DceLriD05aXg19YjnbZ2hs_8odWRRj9lOrqPm9PqAyA=.282bf03c-224d-405f-9574-a26f319433c6@github.com>

On Wed, 22 Oct 2025 10:01:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> SafeFetch was designed specifically for problems like this one.

It was. However, I do not believe we should be in a situation where we are checking a call branch that is the last instruction in a code buffer -- which means there is no need to incur the cost of a SafeFetch. In particular, the failure that happened here only arose because a `far_jump` was used instead of a `far_call`. If a `far_call` had been generated then the value in lr would have been the last word in the buffer rather than a word off the end.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3432012676

From stefank at openjdk.org  Wed Oct 22 13:21:09 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Oct 2025 13:21:09 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
Message-ID: <1kOiLxe1Tj1aHVgliTVBfNvnSuAUUton2j9YW2xlWeo=.1c6e3095-9b5f-49cc-b87a-a897f2a0949f@github.com>

On Tue, 21 Oct 2025 15:16:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change streaming/mapping states to be binary instead of tri states

Fix for minimal:

diff --git a/src/hotspot/share/cds/heapShared.hpp b/src/hotspot/share/cds/heapShared.hpp
index 8fa00b8f47d..4cf3e53011e 100644
--- a/src/hotspot/share/cds/heapShared.hpp
+++ b/src/hotspot/share/cds/heapShared.hpp
@@ -576,9 +576,9 @@ class HeapShared: AllStatic {
   static void setup_test_class(const char* test_class_name) PRODUCT_RETURN;
 #endif // INCLUDE_CDS_JAVA_HEAP

+ public:
   static void finish_materialize_objects() NOT_CDS_JAVA_HEAP_RETURN;

- public:
   static void write_heap(ArchiveMappedHeapInfo* mapped_heap_info, ArchiveStreamedHeapInfo* streamed_heap_info) NOT_CDS_JAVA_HEAP_RETURN;
   static objArrayOop scratch_resolved_references(ConstantPool* src);
   static void add_scratch_resolved_references(ConstantPool* src, objArrayOop dest) NOT_CDS_JAVA_HEAP_RETURN;

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3432332019

From stefank at openjdk.org  Wed Oct 22 13:44:57 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 22 Oct 2025 13:44:57 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
Message-ID: <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>

On Tue, 21 Oct 2025 15:16:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change streaming/mapping states to be binary instead of tri states

Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3432428816

From mdoerr at openjdk.org  Wed Oct 22 14:15:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 22 Oct 2025 14:15:22 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <kjOyL3ITlJABvb6bLszTY3neOZ_ar_pkPq36xsHMv-A=.a462171b-fd91-4e38-9d63-9d56f459f2ed@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

Btw. the disassembled instructions above are coming from https://github.com/openjdk/jdk/pull/27530 which we currently use in our test environment. Reviews would help to get it integrated.

0x0000f7cf03c5fff8:   62 74 ef 17 ff ff ff 17 
--------------------------------------------------------------------------------
  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3432573526

From aph at openjdk.org  Wed Oct 22 14:31:27 2025
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 22 Oct 2025 14:31:27 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <DceLriD05aXg19YjnbZ2hs_8odWRRj9lOrqPm9PqAyA=.282bf03c-224d-405f-9574-a26f319433c6@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
 <J2DHNz3YliRPO53yr78nradBQlhA8PPv4bj1VYbrIEg=.dc30c67d-806b-47ca-81de-087931b8ccb8@github.com>
 <DceLriD05aXg19YjnbZ2hs_8odWRRj9lOrqPm9PqAyA=.282bf03c-224d-405f-9574-a26f319433c6@github.com>
Message-ID: <5iAA02mfIcpLopYEOzalRicQdisil2rAJetzwkSPNQM=.62fda538-ef10-48e7-b741-e17150de4d22@github.com>

On Wed, 22 Oct 2025 12:00:04 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> > SafeFetch was designed specifically for problems like this one.
> 
> It was. However, I do not believe we should be in a situation where we are checking a call branch that is the last instruction in a code buffer -- which means there is no need to incur the cost of a SafeFetch.

It's still incorrect, though, because we can't guarantee that a call can't be at the end of a mapped region. Please include this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3432654503

From acobbs at openjdk.org  Wed Oct 22 15:21:43 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 22 Oct 2025 15:21:43 GMT
Subject: RFR: 8344159: Add lint warnings for unnecessary warning
 suppression [v4]
In-Reply-To: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
References: <w9Uw7WyRjoWUkgoiMQ8LxuA27EBeyUvw0kUD6vSQvvM=.17b4bc9a-ed4e-4a30-b2c1-ad9b2ace4e6a@github.com>
Message-ID: <mHC6vbCdDTDOUixEI-cZeIvxCy2CEzGlW14LdKzINwE=.0b3e1e71-583b-48ab-9546-3485a1a61e01@github.com>

> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings.
> 
> Summary of code changes:
> 
> * Add new warning and associated lint category `"suppression"`
> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ?
> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect.
> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression.
> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations.
> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break
> 
> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 133 commits:

 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflict.
 - Merge branch 'master' into JDK-8344159 to fix conflicts.
 - Add clarifying comment.
 - Merge branch 'master' into JDK-8344159
 - Change inner class name to avoid shadowing superclass name.
 - Add a couple of code clarification comments.
 - Refactor test to avoid requiring changes to TestRunner.
 - Remove unnecessary -Xlint:-suppression flags.
 - Minor cleanups.
 - ... and 123 more: https://git.openjdk.org/jdk/compare/a1be2979...f2b75547

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

Changes: https://git.openjdk.org/jdk/pull/25167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=03
  Stats: 1665 lines in 34 files changed: 1490 ins; 49 del; 126 mod
  Patch: https://git.openjdk.org/jdk/pull/25167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167

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

From duke at openjdk.org  Wed Oct 22 16:11:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 22 Oct 2025 16:11:53 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v2]
In-Reply-To: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
Message-ID: <1mJDNP4BPxU6lH_5D0Z7V_zssJMjfzT9VCC42c89r1Y=.dcc53858-9d25-475c-937c-1f7f3f956234@github.com>

On Wed, 15 Oct 2025 10:14:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move from j.l.management to com.sun.management etc.
>
> Or:
> 
> 
>      * @implNote Time calculation is implementation-specific, and may include details
> 	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
> 	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

@kevinjwalls 

> Particularly on this method about GC time, I don't really follow the reasoning for not accepting the method in java.lang.MemoryMXBean.
>
> The most generic Java API can admit that Java is Garbage-Collected, and that doing that work can take some CPU time.

I think I'm leaning towards jdk.lang/com.sun over java.lang since there are GC algorithms out there (which we don't have in HotSpot), that make this method sometimes less useful. A method in java.lang may need to consider the most generic situation. For instance, GCs that pushes out most of its work onto mutators. It may be hard to accurately measure this at mutator level and we don't want to force JDK implementors to do so. As such this should be categorized as a JDK-specific method. I understand we would prefer jdk.lang over com.sun for new additions?

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

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3433172604

From kdnilsen at openjdk.org  Wed Oct 22 17:22:46 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 22 Oct 2025 17:22:46 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v28]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <Uj9m3_g8s-_EpLhtbEIs75BF7eUsLShQg1-85sYMOdw=.e994b4a3-c3cc-4db9-8556-fd412a46c6b9@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Add sleep to CompressedClassSpaceSizeInJmapHeap.java test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/ee617c30..da92c344

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=26-27

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

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

From cjplummer at openjdk.org  Wed Oct 22 20:58:55 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 Oct 2025 20:58:55 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v5]
In-Reply-To: <2fEidZb-lqK9yIMdmSuFndkHzO5dBxILPn9wmrfQqyc=.ad68690c-e3c8-4009-a974-159d6af93664@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
 <2fEidZb-lqK9yIMdmSuFndkHzO5dBxILPn9wmrfQqyc=.ad68690c-e3c8-4009-a974-159d6af93664@github.com>
Message-ID: <0raSCM3ULWMIn4Qjji24dbNcZr2OCeEgJTOII7sppWQ=.34791f0b-4bae-4d3c-9fd7-1a60cc3ba703@github.com>

On Wed, 22 Oct 2025 08:48:47 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
>> 
>> - Removed x86-specific implementations and ifdef blocks.
>> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
>> - Cleaned up platform detection logic in `PlatformInfo`.
>> - Updated documentation references.
>
> Kerem Kat has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "run RotateLeftNode*IdealizationTests on amd64 too"
>   
>   This reverts commit 1011b304f7cb4d195efc9239acd7784053c67cc1.

Overall the changes look good. I just requested some updates on some of the comments. I'm about to be OOO for close to a week, so I'll follow up on this when I return.

src/jdk.hotspot.agent/doc/hsdb.html line 34:

> 32:  <li> Class Browser - view Java classes, bytecode disassembly,
> 33:    or create .class files for selected classes
> 34:  <li> native disassembly (amd64 only) and nmethod disassembly with annotations for safepoint details.

"requires hsdis"

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java line 54:

> 52: 
> 53:   // The returned array of register contents is guaranteed to be in
> 54:   // the same order as in the DbxDebugger for Solaris or amd64; that is,

I think the original wording implied "Solaris/x86 or Solaris/amd64", so I think the updated text should just read "Solaris/amd64".

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/debugger/windbg/WindbgDebugger.java line 55:

> 53:   // The returned array of register contents is guaranteed to be in
> 54:   // the same order as in the DbxDebugger for Solaris or amd64; that is,
> 55:   // the indices match those in debugger/amd64/AMD64ThreadContext.java or

Now you have debugger/amd64/AMD64ThreadContext.java both on this line and the next. You need to reduce it to just one occurrence.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/amd64/AMD64Frame.java line 39:

> 37: 
> 38: /** Specialization of and implementation of abstract methods of the
> 39:     Frame class for the x86-64 family of CPUs. */

"x86_64"

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

PR Review: https://git.openjdk.org/jdk/pull/27844#pullrequestreview-3367452899
PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2453284822
PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2453320919
PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2453324086
PR Review Comment: https://git.openjdk.org/jdk/pull/27844#discussion_r2453327438

From cjplummer at openjdk.org  Wed Oct 22 21:02:37 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 22 Oct 2025 21:02:37 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
Message-ID: <O2aK1E_HNMxwpp_DxG1cKOn1sdEvfvnmNOCS-e6_4hs=.341df00c-1f5d-4be8-88cc-458c312cdc25@github.com>

On Mon, 20 Oct 2025 06:59:42 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
>> 
>> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
>> 
>> 
>> ----------------- 646689 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
>> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
>> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
>> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 
>> 
>> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
>> 
>> 
>> ----------------- 646841 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
>> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
>> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
>> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
>> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
>> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
>> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
>> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
>> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
>> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
>> 0x00007f4a08fc31bb JavaCalls::call_virtu...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcase

Changes look good. Thanks for fixing this.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27885#pullrequestreview-3367531182

From sspitsyn at openjdk.org  Wed Oct 22 21:20:50 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 21:20:50 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <ucrHL3nlJgKb7E_2KHjyxrMpGylqA6BGsESX3iPRB0w=.cb058e91-3254-4daf-b987-76e1ead00c06@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/6f9bacd9...1dafec32

Marked as reviewed by sspitsyn (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3367580190

From lmesnik at openjdk.org  Wed Oct 22 21:39:11 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 22 Oct 2025 21:39:11 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <CTime1EP201OKQEGclEXb6y0DSE44d7Z6us3y2K8iCo=.5cbf8ee2-9b63-477d-98c4-cd2aa4f213ec@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/99431d1f...1dafec32

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27766#pullrequestreview-3367619935

From duke at openjdk.org  Wed Oct 22 21:45:40 2025
From: duke at openjdk.org (duke)
Date: Wed, 22 Oct 2025 21:45:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <dTtuCCP3VlnvnGwEgNcviisq3DDMigSX-Zcwkf16F_s=.d7dc9da0-ec3a-45f7-b122-a3d652eb7672@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/a9898f46...1dafec32

@fandreuz 
Your change (at version 1dafec32b57ac557b66dfe91c4bd2964019c9ff1) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3434297134

From sspitsyn at openjdk.org  Wed Oct 22 21:45:40 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 21:45:40 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v17]
In-Reply-To: <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <3yCUt0KktGQmUC0mwHOfHp9XMf0QJFLz1ZIqxFX7niI=.ac5f4e59-9030-4998-9c40-b1dafa3b76a3@github.com>
Message-ID: <2JEh_c2gMQIJurFDLNjpaO3ydq0B2n78STax6f2zI7Y=.b844616e-98cb-46ab-a207-c431f2b3bb1b@github.com>

On Wed, 22 Oct 2025 08:41:15 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Francesco Andreuzzi 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 40 additional commits since the last revision:
> 
>  - rename
>  - Merge branch 'master' into JDK-8359472
>  - return value
>  - cc
>  - empty stderr
>  - jvmti errors
>  - indent
>  - close
>  - rephrase
>  - PidJcmdExecutor. unused import. cc
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/a9898f46...1dafec32

Thank you for the updates!

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3434297489

From sspitsyn at openjdk.org  Wed Oct 22 21:45:42 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 22 Oct 2025 21:45:42 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v13]
In-Reply-To: <MkqgOBIlKQflEWsM92DgkKXyeoeRbnRAaLklgILDtw0=.9584a734-e082-4694-bf10-f9c41f30ee09@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <d-Nyie7sHE7jQfeuy1TTj1FGq1GeS93Y-gTjgAXrWC8=.a97e35f9-27ca-44b0-bc25-1f4ae7fe0336@github.com>
 <guOPL7awu7x9vWZ00AqdtjpQGia6ULeNna9YMjkVY9s=.6fce596e-1859-4872-b219-101db1269c40@github.com>
 <MkqgOBIlKQflEWsM92DgkKXyeoeRbnRAaLklgILDtw0=.9584a734-e082-4694-bf10-f9c41f30ee09@github.com>
Message-ID: <32BnXBMwR8EaozsDvNyBfNdBFUwNOyWW3abUCgsdd3w=.a4922c46-d388-4e77-88c1-29cdc9703a0f@github.com>

On Tue, 21 Oct 2025 09:28:21 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/attach/EarlyDynamicLoad/libEarlyDynamicLoad.cpp line 47:
>> 
>>> 45: 
>>> 46:     jvmti->SetEventCallbacks(&callbacks, sizeof(callbacks));
>>> 47:     jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VM_START, nullptr);
>> 
>> Nit: Even though it is normally works well it'd be better to check and handle the `jvmtiError` code returned from the JVMTI functions. You can easily find some examples to follow. Also, the indent for native code has to be 2, not 4.  It is possible, you can find some tests where this kind of check/handling is missed or the indent is incorrect. It does not mean we should have these bad habits with new tests. :)
>
> Fixed in a401f0a118785f600e70ca0099802ff05e967bc9 and 925f9fc828597f920e4b800d63428e414f8b0345. I thought the error could be printed with `jvmti->GetErrorName`, but I guess that would introduce unnecessary complication. Let me know what you think @sspitsyn.

Usually, we use the test library functions `check_jvmti_error()` and `check_jvmti_status()` from the `test/lib/jdk/test/lib/jvmti/jvmti_common.hpp`. The `jvmti->GetErrorName()` can be used there but it is not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27766#discussion_r2453414160

From fandreuzzi at openjdk.org  Wed Oct 22 21:45:34 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 21:45:34 GMT
Subject: RFR: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE [v8]
In-Reply-To: <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
 <4Bivnv21ix1jGYdX_frkp3UeSot3hAEp503nHZjw_5s=.f5c6421a-709c-4e3c-9246-165b3561e83f@github.com>
 <cKjf5XMIotVSsFtlTI1v6lrOrauxsSCbNPmaeANjGA0=.0dd5ed44-2d56-42d0-a0c6-b63eb9288249@github.com>
Message-ID: <QzeAsbPW6NlEGulMufStCbCpOCK4NFzmXRcCXFjVXl4=.03d85465-15c1-470a-9c01-ea02f7ad6d2b@github.com>

On Thu, 16 Oct 2025 22:31:57 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - revert
>>  - replace
>
> The approach looks okay to me. Thank you for taking care about this issue!

Thanks for the review @sspitsyn, @sspitsyn, @alexmenkov and @dholmes-ora.

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

PR Comment: https://git.openjdk.org/jdk/pull/27766#issuecomment-3434293942

From fandreuzzi at openjdk.org  Wed Oct 22 21:50:38 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 21:50:38 GMT
Subject: Integrated: 8359472: JVM crashes when attaching a dynamic agent before
 JVMTI_PHASE_LIVE
In-Reply-To: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
References: <-4JllopG-fC-rIgolKoVmc116IUFOGR8XYsynq-DQio=.b2a64d25-78bf-4835-882c-af2769b9f659@github.com>
Message-ID: <lynjWEOl6hkABzTog2n6gqJiVWi6IOyj7RU8yJqnkgs=.11b843bc-f202-4b72-a89d-af78c8f743cb@github.com>

On Mon, 13 Oct 2025 11:26:36 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> In this PR I add a check to prevent debug builds to crash when an agent tries to attach while the JVM is not in live phase.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: 2a8cbd94
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a8cbd944ba4d8896e48181e396c65f70e5aa215
Stats:     167 lines in 3 files changed: 167 ins; 0 del; 0 mod

8359472: JVM crashes when attaching a dynamic agent before JVMTI_PHASE_LIVE

Reviewed-by: lmesnik, sspitsyn, amenkov

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

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

From fyang at openjdk.org  Thu Oct 23 03:11:08 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 23 Oct 2025 03:11:08 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
Message-ID: <25ErJcLPigrje8E19kL26G1KUnuewSxY3yliGAIWA_Q=.de94a1d4-1ebc-48f6-b156-39c97451ab33@github.com>

On Mon, 20 Oct 2025 06:59:42 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
>> 
>> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
>> 
>> 
>> ----------------- 646689 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
>> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
>> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
>> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 
>> 
>> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
>> 
>> 
>> ----------------- 646841 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
>> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
>> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
>> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
>> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
>> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
>> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
>> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
>> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
>> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
>> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
>> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
>> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
>> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
>> 0x00007f4a08fc31bb JavaCalls::call_virtu...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update testcase

@YaSuenag : 
Hi, I tried the test on linux-riscv64 and seems this platform bears the same issue.
Would you mind adding this add-on fix for this platform please? Thanks.
[8370176-riscv64.diff.txt](https://github.com/user-attachments/files/23077241/8370176-riscv64.diff.txt)

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

PR Comment: https://git.openjdk.org/jdk/pull/27885#issuecomment-3434903817

From fyang at openjdk.org  Thu Oct 23 03:17:06 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 23 Oct 2025 03:17:06 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
Message-ID: <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>

On Tue, 21 Oct 2025 05:44:00 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackMixedWithXComp.java line 40:
>> 
>>> 38:  * @bug 8370176
>>> 39:  * @requires vm.hasSA
>>> 40:  * @requires os.family == "linux"
>> 
>> Do Windows and OSX have a similar problem that should be fixed also?
>
> This problem is in mixed mode (`PStack`) only, thus we need to skip OSX because [you mentioned](https://github.com/openjdk/jdk/pull/27728#issuecomment-3392919979) mixed mode is not supported on OSX.
> 
> In Windows, I'm not sure, but I guess we need to consider `UNWIND_INFO` to unwind call frames correctly like DWARF in Linux, however it hasn't done yet. Thus we can think mixed mode is not supported in Windows too, so I didn't add Windows here.
> https://learn.microsoft.com/cpp/build/exception-handling-x64
> 
> Actually I could not see all of stacks as following in mixed mode. It works in normal mode (without `--mixed`) of course. (I tested it on Windows 11 x64, upstream JDK built by VS 2022)
> 
> ----------------- 13 -----------------
> "Reference Handler" #15 daemon prio=10 tid=0x00000207280b9f70 nid=12684 waiting on condition [0x000000aaf6aff000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_blocked
> 0x00007fffa6b45844      ntdll!NtWaitForAlertByThreadId + 0x14
> 0x00000000ffffffff              ????????

Mind you that this new test seems to fail even on linux systems without pstack. This is happening on both of my AMD64 machine running Debian 12 and ARM64 machine running Ubuntu 22.04.4.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2453813619

From ysuenaga at openjdk.org  Thu Oct 23 04:46:42 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 23 Oct 2025 04:46:42 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v3]
In-Reply-To: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
Message-ID: <EtVE09PIu4kQF_H7ZwC6Vax5c2sGxkF-i_A8gXNWl5Q=.35bc99f2-0dc3-4697-b8e4-344d374168cc@github.com>

> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
> 
> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
> 
> 
> ----------------- 646689 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 
> 
> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
> 
> 
> ----------------- 646841 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
> 0x00007f4a08fc31bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
> 0x00007f4a091...

Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:

 - Add the fix for RISC-V
 - Remove debug messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27885/files
  - new: https://git.openjdk.org/jdk/pull/27885/files/a75aa29d..0e7c4ccd

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

  Stats: 31 lines in 2 files changed: 15 ins; 7 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27885/head:pull/27885

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

From ysuenaga at openjdk.org  Thu Oct 23 04:46:43 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 23 Oct 2025 04:46:43 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <25ErJcLPigrje8E19kL26G1KUnuewSxY3yliGAIWA_Q=.de94a1d4-1ebc-48f6-b156-39c97451ab33@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <25ErJcLPigrje8E19kL26G1KUnuewSxY3yliGAIWA_Q=.de94a1d4-1ebc-48f6-b156-39c97451ab33@github.com>
Message-ID: <iQGd33AcX-dyd0ggRP501XdsR3wfgvc5rrW3jArF9zA=.32b228bf-e99b-4fb7-b372-8568d6fcdb28@github.com>

On Thu, 23 Oct 2025 03:08:51 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase
>
> @YaSuenag : 
> Hi, I tried the test on linux-riscv64 and seems this platform bears the same issue.
> Would you mind adding this add-on fix for this platform please? Thanks.
> [8370176-riscv64.diff.txt](https://github.com/user-attachments/files/23077241/8370176-riscv64.diff.txt)

@RealFYang Thanks a lot for sharing a patch for RISC-V! Merged to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27885#issuecomment-3435049405

From ysuenaga at openjdk.org  Thu Oct 23 04:46:43 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 23 Oct 2025 04:46:43 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
 <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
Message-ID: <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>

On Thu, 23 Oct 2025 03:13:43 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> This problem is in mixed mode (`PStack`) only, thus we need to skip OSX because [you mentioned](https://github.com/openjdk/jdk/pull/27728#issuecomment-3392919979) mixed mode is not supported on OSX.
>> 
>> In Windows, I'm not sure, but I guess we need to consider `UNWIND_INFO` to unwind call frames correctly like DWARF in Linux, however it hasn't done yet. Thus we can think mixed mode is not supported in Windows too, so I didn't add Windows here.
>> https://learn.microsoft.com/cpp/build/exception-handling-x64
>> 
>> Actually I could not see all of stacks as following in mixed mode. It works in normal mode (without `--mixed`) of course. (I tested it on Windows 11 x64, upstream JDK built by VS 2022)
>> 
>> ----------------- 13 -----------------
>> "Reference Handler" #15 daemon prio=10 tid=0x00000207280b9f70 nid=12684 waiting on condition [0x000000aaf6aff000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_blocked
>> 0x00007fffa6b45844      ntdll!NtWaitForAlertByThreadId + 0x14
>> 0x00000000ffffffff              ????????
>
> Mind you that this new test seems to fail even on linux systems without pstack. This is happening on both of my AMD64 machine running Debian 12 and ARM64 machine running Ubuntu 22.04.4.

Can you share .jtr file?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2453904309

From ysuenaga at openjdk.org  Thu Oct 23 04:51:02 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 23 Oct 2025 04:51:02 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <O2aK1E_HNMxwpp_DxG1cKOn1sdEvfvnmNOCS-e6_4hs=.341df00c-1f5d-4be8-88cc-458c312cdc25@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <O2aK1E_HNMxwpp_DxG1cKOn1sdEvfvnmNOCS-e6_4hs=.341df00c-1f5d-4be8-88cc-458c312cdc25@github.com>
Message-ID: <S6bEOxofcZrcga-82kQf1Herxx5Tx8xQ2CRY2cIrDjM=.b95f648d-b126-4081-8a66-e01c6e33a59c@github.com>

On Wed, 22 Oct 2025 21:00:22 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update testcase
>
> Changes look good. Thanks for fixing this.

@plummercj Thanks a lot for your review!

I'm trying to fix mixed mode on Windows. I think we can unwind native stacks with [this change](https://github.com/YaSuenag/jdk/commit/71fc6df3d9e46e03d956f08c03fdefc6e12586fd), but it is not enough for Java frames - I think we can see all of them if we modify after this PR.

----------------- 13 -----------------
"Reference Handler" #15 daemon prio=10 tid=0x000001a8df240270 nid=4800 waiting on condition [0x0000002207fff000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_blocked
0x00007fff725a5844      ntdll!NtWaitForAlertByThreadId + 0x14
0x00007fff7244c30b      ntdll!RtlSleepConditionVariableCS + 0x14b
0x00007fff6f6ca688      KERNELBASE!SleepConditionVariableCS + 0x38
0x00007ffed580c92d      jvm!PlatformMonitor::wait + 0x3d
0x00007ffed5796f3f      jvm!Monitor::wait + 0x15f
0x00007ffed5448310      jvm!JVM_WaitForReferencePendingList + 0xb0
0x000001a8ce87fa18      <interpreter> native method entry point (kind = native)
0x000001a8df240710              ????????
0x0000002207fffa38              ????????
0x000001a8df240270              ????????
0x000001a8e000bd98              ????????
0x000001a8ce87f39b      <interpreter> native method entry point (kind = native)
0xfffffffffffffff7              ????????
0x000000003e871a28              ????????
0x0000000000000003              ????????
0x000000003e2054f8              ????????

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

PR Comment: https://git.openjdk.org/jdk/pull/27885#issuecomment-3435068616

From fyang at openjdk.org  Thu Oct 23 06:19:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 23 Oct 2025 06:19:02 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
 <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
 <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>
Message-ID: <1pCb9jVqE1g4rIHCQTyUNU3HX1mm_30MI0Ux9_WyBD8=.31174776-e691-445b-b288-ba97272e637a@github.com>

On Thu, 23 Oct 2025 04:42:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Mind you that this new test seems to fail even on linux systems without pstack. This is happening on both of my AMD64 machine running Debian 12 and ARM64 machine running Ubuntu 22.04.4.
>
> Can you share .jtr file?

Sure. This is what I got on my amd64 machine:

```$ make test TEST="serviceability/sa/TestJhsdbJstackMixedWithXComp.java"```

[TestJhsdbJstackMixedWithXComp.jtr.txt](https://github.com/user-attachments/files/23091141/TestJhsdbJstackMixedWithXComp.jtr.txt)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2454028951

From ysuenaga at openjdk.org  Thu Oct 23 07:26:05 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 23 Oct 2025 07:26:05 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <1pCb9jVqE1g4rIHCQTyUNU3HX1mm_30MI0Ux9_WyBD8=.31174776-e691-445b-b288-ba97272e637a@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
 <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
 <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>
 <1pCb9jVqE1g4rIHCQTyUNU3HX1mm_30MI0Ux9_WyBD8=.31174776-e691-445b-b288-ba97272e637a@github.com>
Message-ID: <VU0aXhIIV_c9P-QSAWP0hZMm9aNM1UsHrbsZbsKOy3A=.9041a0b4-1738-4264-a53d-b6829d685bd3@github.com>

On Thu, 23 Oct 2025 06:14:53 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Can you share .jtr file?
>
> Sure. This is what I got on my amd64 machine:
> 
> ```$ make test TEST="serviceability/sa/TestJhsdbJstackMixedWithXComp.java"```
> 
> [TestJhsdbJstackMixedWithXComp.jtr.txt](https://github.com/user-attachments/files/23091141/TestJhsdbJstackMixedWithXComp.jtr.txt)

@RealFYang Thank you for sharing it!

I think it might be caused by binary difference, it is not caused by this PR at least. So I think we can go forward this PR, make sence?

Your .jtr file implies stack unwinding was failed from the function by libc in following:

----------------- 2310034 -----------------
"SteadyStateThread" #39 prio=5 tid=0x00007fd2600358a0 nid=2310034 waiting for monitor entry [0x00007fd2351f4000]
   java.lang.Thread.State: BLOCKED (on object monitor)
   JavaThread state: _thread_blocked
0x00007fd267930f16      __futex_abstimed_wait_common + 0xc6
----------------- 2310033 -----------------
"ForkJoinPool-1-worker-2" #38 daemon prio=5 tid=0x00007fd1ec006600 nid=2310033 runnable [0x00007fd2352f5000]
   java.lang.Thread.State: RUNNABLE
   JavaThread state: _thread_in_native
0x00007fd26797a545      __clock_nanosleep + 0x65
0x00007fd26797ee53      __GI___nanosleep + 0x13


Native stack unwinding on Linux AMD64 depends on DWARF (in AArch64, it depends on FP (x29) yet).
I downloaded and checked libc.so.6 in libc6-udeb_2.41-12_amd64.udeb, it has `.eh_frame` section which would be used by `DwarfParser`, but it does not have any symbols, and not have `.gnu_debuglink` ELF section. OTOH Fedora 43 which I confirmed to work has both symbols and `.gnu_debuglink`.

They are used for symbol resolution, not stack unwinding. However other difference(s) in binary might affect statck unwinding. Thus I think it is not a problem caused by this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2454170838

From iwalulya at openjdk.org  Thu Oct 23 08:32:08 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 23 Oct 2025 08:32:08 GMT
Subject: RFR: 8369186: HotSpot Style Guide should permit some uses of the
 C++ Standard Library [v4]
In-Reply-To: <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
References: <kY6l9hzC-_-0OTsD7XFX0UUH8HdaqWLzpFngxKtUWvo=.c84a320a-cc73-42aa-93f0-4e4eaddc3390@github.com>
 <ID8CMpHtt0565jojsV0JdiALZzK64N-7zEAs5e33R40=.a93fa3b1-b0ac-49f0-8a5e-b6ac80337509@github.com>
Message-ID: <vZ97HL26jFcy2AndqwbM-oUk2aS2PYwzHYCIh_5nPCU=.e93b2b9b-6fd5-43fa-a774-331a3cd91205@github.com>

On Sat, 18 Oct 2025 17:11:48 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the HotSpot Style Guide to suggest that C++
>> Standard Library components may be used, after appropriate vetting and
>> discussion, rather than just a blanket "no, don't use it" with a few very
>> narrow exceptions. It provides some guidance on that vetting process and
>> the criteria to use, along with usage patterns.
>> 
>> In particular, it proposes that Standard Library headers should not be
>> included directly, but instead through HotSpot-provided wrapper headers. This
>> gives us a place to document usage, provide workarounds for platform issues in
>> a single place, and so on.
>> 
>> Such wrapper headers are provided by this PR for `<cstddef>`, `<limits>`, and
>> `<type_traits>`, along with updates to use them. I have a separate change for
>> `<new>` that I plan to propose later, under JDK-8369187. There will be
>> additional followups for other C compatibility headers besides `<cstddef>`.
>> 
>> This PR also cleans up some nomenclature issues around forbid vs exclude and
>> the like.
>> 
>> Testing: mach5 tier1-5, GHA sanity tests
>
> Kim Barrett 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 stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - Merge branch 'master' into stdlib-header-wrappers
>  - jrose comments
>  - move tuple to undecided category
>  - add wrapper for <type_traits>
>  - add wrapper for <cstddef>
>  - add wrapper for <limits>
>  - style guide permits some standard library facilities

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27601#pullrequestreview-3368792334

From fbredberg at openjdk.org  Thu Oct 23 08:37:34 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 23 Oct 2025 08:37:34 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
Message-ID: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>

This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.

The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.

This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.

Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

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

Commit messages:
 - Small arm32 fix
 - Small include line fix
 - 8367982: Unify ObjectSynchronizer and LightweightSynchronizer

Changes: https://git.openjdk.org/jdk/pull/27915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8367982
  Stats: 2851 lines in 76 files changed: 1233 ins; 1369 del; 249 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

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

From fbredberg at openjdk.org  Thu Oct 23 08:41:12 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Thu, 23 Oct 2025 08:41:12 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

@bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar
Hi guys!
This is the last PR in a series of PRs to obsolete the `LockingMode` flag and related code.
So please please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it.
Thanks in advance.

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

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3435760553

From duke at openjdk.org  Thu Oct 23 08:52:10 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 23 Oct 2025 08:52:10 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
Message-ID: <2RzS-r62ah63nIObdN26fCrtKDTBnYNe9pJKcXo-170=.833a9a74-d124-497c-a977-06adc52750ef@github.com>

On Tue, 21 Oct 2025 13:56:57 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

> What it does is a 4 byte read at the supplied pc (i.e one instruction's worth of data) to test whether those bytes encode a nop instruction

I meant to refer to this `check` implementation, which reads 8 bytes from where `LR` points to and checks whether they contain the NOP+MOVK sequence.

https://github.com/openjdk/jdk/blob/dcf46a0a195d7386ed0bc872f60eb9c586425cc8/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp#L531

class NativePostCallNop: public NativeInstruction {
public:
  bool check() const {
    uint64_t insns = *(uint64_t*)addr_at(0);
    // Check for two instructions: nop; movk zr, xx
    // These instructions only ever appear together in a post-call
    // NOP, so it's unnecessary to check that the third instruction is
    // a MOVK as well.
    return (insns & 0xffe0001fffffffff) == 0xf280001fd503201f;
  }
  ```

In case of deoptimization, the LR is pointing to the entry point of the deoptimization handler stub code located one instruction before the end of the code blob - in this case, `0x0000f7cf03c5fffc`:


  0x0000f7cf03c5fff8:   b	0x0000f7cf0383d180
  0x0000f7cf03c5fffc:   b	0x0000f7cf03c5fff8


If I understand correctly, the `si_addr` reported by the kernel for the SIGSEGV is the address of memory location which caused the SIGSEGV. In this case it would be reported as follows, both in case the memory access was 8-byte starting at `0x0000f7cf03c5fffc` or 4-byte starting at `0x0000f7cf03c60000`:

siginfo: si_signo: 11 (SIGSEGV), si_code: 2 (SEGV_ACCERR), si_addr: 0x0000f7cf03c60000


It should be possible to solve this by either using SafeFetch or by checking for NOP and MOVK separately in 4-byte reads. Both should work, however it appears the latter might be preferrable: the outcome of the check should not depend on anything outside the current code blob. Using SafeFetch can hide the issue.


@theRealAph, thank you for the advice on the SafeFetch interface - I wasn't aware it exists.
However, as it might introduce performance overhead on what appears to be designed as a fast path, and potentially might hide this kind of issue where content outside the code blob is checked, would it be suitable for you if the alternative is implemented?

The `check` is only meant to access the bytes pointed to by return address. I believe it wouldn't be correct for it to check an arbitrary location as there are no guarantees to match the constraints expected by the NativePostCallNop logic outside the compiled code. So, it should only be reading within the compiled code. When continuations are enabled, every call site should have the post-call NOP sequences following it.
The exception to this is deoptimization - where the perceived call site actually is within the deoptimization handler stub code and, with this change, is followed by the entry point of the stub code. The entry point is never going to be a NOP, so checking for NOP first would prevent the second read checking for MOVK.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3435796978

From duke at openjdk.org  Thu Oct 23 09:03:39 2025
From: duke at openjdk.org (Ruben)
Date: Thu, 23 Oct 2025 09:03:39 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
Message-ID: <URgBhHO4qIMlpIuj92Dzt8Cm2qLuwGrGKrri8VdViLM=.d26cb92e-bc21-451d-8bcd-49bdf0db929a@github.com>

On Mon, 13 Oct 2025 11:45:02 GMT, Ruben <duke at openjdk.org> wrote:

>> The C2 exception handler stub code is only a trampoline to the generated exception handler blob. This change removes the extra step on the way to the generated blob.
>> 
>> According to some comments in the source code, the exception handler stub code used to be patched upon deoptimization, however presumably these comments are outdated as the patching upon deoptimization happens for post-call NOPs only.
>
> Ruben has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge from the main branch
>  - Address review comments
>  - Address review comments
>  - Address review comments
>  - The patch is contributed by @TheRealMDoerr
>  - Offset the deoptimization handler entry point
>    
>    Change-Id: I596317ec6a364b341e4642636fa5cf08f87ed722
>  - Revert "Ensure stub code is not adjacent to a call"
>  - Ensure stub code is not adjacent to a call
>  - Address review comments
>  - 8365047: Remove exception handler stub code in C2
>    
>    The C2 exception handler stub code is only a trampoline to the
>    generated exception handler blob. This change removes the extra
>    step on the way to the generated blob.
>    
>    According to some comments in the source code, the exception handler
>    stub code used to be patched upon deoptimization, however presumably
>    these comments are outdated as the patching upon deoptimization happens
>    for post-call NOPs only.

I've also looked into the `far_jump` vs `far_call` issue - attempting to identify why tests on my side didn't catch this.
It appears that normally methods load the return address from stack to `LR` before using `RET`, so by chance the `LR` happens to point to the entry point of the stub code upon entering the stub code.

I've managed to reproduce a situation when it isn't the case - deoptimization of parked virtual threads - where the control flow is transferred to the deoptimization handler stub code via the signal handler. In this case, the LR is pointing to the post-call sequence (which was patched to cause a `SIGILL`) within the same method. However, even in this case, the test completed successfully as apparently the `fetch_unroll_info_helper` is designed in a way that can handle both frames pointing to deoptimized methods and frames to non-deoptimized methods where execution should continue in interpreter (for example, uncommon trap).

It might be beneficial to add an assertion in the `fetch_unroll_info_helper` that ensures, for case `exec_mode` is `Unpack_deopt` (and potentially, for `Unpack_exception` too) that the LR is indeed pointing to the deoptimization handler stub code.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3435836587

From eosterlund at openjdk.org  Thu Oct 23 09:34:09 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 09:34:09 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v8]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <ASHQR1eTDVtk-Sfr7Oe_zVYbEdhoQw3zQt64C83WUpI=.d266ffee-2a3c-4a19-bfb2-7057f9408bc8@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Fix for minimal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/70fb7acc..99726c72

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

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

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

From adinn at openjdk.org  Thu Oct 23 09:44:18 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Thu, 23 Oct 2025 09:44:18 GMT
Subject: RFR: 8365047: Remove exception handler stub code in C2 [v7]
In-Reply-To: <2RzS-r62ah63nIObdN26fCrtKDTBnYNe9pJKcXo-170=.833a9a74-d124-497c-a977-06adc52750ef@github.com>
References: <4R-933Vw15ku03kFonQY4msXdmzkNVnawVWFB7Uu4k0=.1653f2ec-79d1-4076-aa03-4bae566d74c2@github.com>
 <01PUPvM0-KXiJK5JwUaaEi0e5qJdU0wE5tVHojKa3AY=.594c34c0-1ee3-4794-8e93-f0d742fcbfda@github.com>
 <ncASElIE2XbLp1MXb5XLMmkZjOcW6Mds3gYtxYL27xo=.ef645145-b82d-4f0f-b333-7db8ee2d84b2@github.com>
 <juY8csgiTiw99zOGjEuD2BKkoCwvoRn-4ByOozs4TH4=.c4afe0b2-7893-47cf-beb5-ee8fe3ff94a3@github.com>
 <WgTpeqiuU4HtASrlZ0C7qkEf_CFcXVAqrGfcecsxZqc=.f75ac053-e57d-4568-8731-fe23c1fa44a5@github.com>
 <2RzS-r62ah63nIObdN26fCrtKDTBnYNe9pJKcXo-170=.833a9a74-d124-497c-a977-06adc52750ef@github.com>
Message-ID: <m_DJYnayvyWlslRy6BJn0gYoKkA5NT_rNOTQIo0AjBQ=.c57489f2-469c-4a90-afb9-046f9fea6392@github.com>

On Thu, 23 Oct 2025 08:48:54 GMT, Ruben <duke at openjdk.org> wrote:

> I meant to refer to this check implementation, which reads 8 bytes from where LR points to and checks whether they contain the NOP+MOVK sequence.

Ah, my apologies for misunderstanding you and also and what was going on in this code. It is indeed reading two instructions at once and checking them both in one go.

I agree with you that this is best split up into two separate reads+checks to deal with the case where we don't have a NOP and might drop off the end of the current buffer. I think this will still be less work than using SafeFetch but @theRealAph may want to override me here.

> It might be beneficial to add an assertion in the `fetch_unroll_info_helper` that ensures, for case `exec_mode` is `Unpack_deopt` (and potentially, for `Unpack_exception` too) that the `LR` is indeed pointing to the deoptimization handler stub code.

That sounds like a good idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/26678#issuecomment-3436002622

From alanb at openjdk.org  Thu Oct 23 11:29:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Oct 2025 11:29:11 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v5]
In-Reply-To: <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>
Message-ID: <wVDMkRhswMMdZj8pTn01HWxdYNsYZgKTEhnGjxikL5A=.70eb9e23-59d2-4585-8bdc-4cc7c683f0d9@github.com>

On Wed, 22 Oct 2025 11:28:34 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 271:

> 269: 
> 270:     /**
> 271:      * Returns the CPU time used by garbage collection.

The latest wording is much better. For the first sentence, you might to consider expanding is a bit to something like "Returns the approximate accumulated time, in nanoseconds, spent in garbage collection."

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 285:

> 283:      * workers, VM Operations and string deduplication (if enabled).
> 284:      * The return value can be -1 if called when measurement is
> 285:      * not possible, such as during shutdown.

For the implNote then I think you are looking to say something HotSpot VM specific. That is possible with something like:  The specifics on what constitutes the time spent in garbage collection is highly implementation dependent. In the HotSpot Virtual Machine implementation, ... 

(If you are using the term "driver threads" then you will probably need to say more on what it means).

It is still the intention to use this in conjunction with OperatingSystemMXBean:: getProcessCpuTime ? If so, this could also be included here, or in an API note.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2454746445
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2454797793

From mdoerr at openjdk.org  Thu Oct 23 12:09:04 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 23 Oct 2025 12:09:04 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <B-c0Ef2m7mIjRjbjIejJ6GXiezMjdPSRp-XqRt0QlY0=.9c07a6d7-471b-4a71-b5cc-973a4d4d9131@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Thanks for cleaning this up on all platforms! Works on PPC64.
Indentation could be improved at many places where the next line was aligned (all platforms and shared code).

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

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3436579205

From krk at openjdk.org  Thu Oct 23 13:05:49 2025
From: krk at openjdk.org (Kerem Kat)
Date: Thu, 23 Oct 2025 13:05:49 GMT
Subject: RFR: 8351194: Clean up Hotspot SA after 32-bit x86 removal [v6]
In-Reply-To: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
References: <c6SzsTWuElVynjfq6gs7V6WVJi452evKqGH6_a5lvQs=.5c73b211-1d0b-45a1-be6a-e716c54b2ff2@github.com>
Message-ID: <8iW_GiBCtv9h3KuLbHs8_oqp-xLgeENFpUewOv7sBA0=.b75de49d-9ee3-492c-9515-f87c44b8412b@github.com>

> Remove 32-bit x86 specific code from the HotSpot Serviceability Agent following the removal of 32-bit x86 support.
> 
> - Removed x86-specific implementations and ifdef blocks.
> - Renamed files with X86 in the name when they are also used from AMD64, e.g. `X86Frame` ? `AMD64Frame`.
> - Cleaned up platform detection logic in `PlatformInfo`.
> - Updated documentation references.

Kerem Kat has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - fix comments
 - Revert "run RotateLeftNode*IdealizationTests on amd64 too"
   
   This reverts commit 1011b304f7cb4d195efc9239acd7784053c67cc1.
 - requires hsdis
 - run RotateLeftNode*IdealizationTests on amd64 too
 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - Merge branch 'master' into clean-x86-sa-JDK-8351194
 - Clean up Hotspot SA after 32-bit x86 removal

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

Changes: https://git.openjdk.org/jdk/pull/27844/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27844&range=05
  Stats: 2780 lines in 45 files changed: 623 ins; 2111 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/27844.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27844/head:pull/27844

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

From kdnilsen at openjdk.org  Thu Oct 23 14:11:16 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 23 Oct 2025 14:11:16 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v29]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <2l4P4pkKeL63Muti7IZhWjXpqBqSxwEoOogPijXY7dE=.242f9bf9-96cd-42d0-91eb-8b403d6279a4@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/da92c344..b107bc5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=27-28

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

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

From eosterlund at openjdk.org  Thu Oct 23 15:50:40 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 15:50:40 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
Message-ID: <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>

On Wed, 22 Oct 2025 13:41:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?

I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3437754817

From iklam at openjdk.org  Thu Oct 23 16:08:49 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 23 Oct 2025 16:08:49 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
 <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
Message-ID: <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>

On Thu, 23 Oct 2025 15:47:55 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
> 
> I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.

We have 


#if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64)
#define INCLUDE_CDS_JAVA_HEAP 1


So we need to make sure it works for 32 bit as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3437850552

From kdnilsen at openjdk.org  Thu Oct 23 16:28:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 23 Oct 2025 16:28:31 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v30]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <CddJy1vG993fIG_dQcqZdM1TvBbfbi518cE3Fppd7Wo=.f149e9b9-aa3f-444f-a201-b641ab76297a@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  fix errors in CompressedClassSpaceSizeInJmapHeap.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/b107bc5c..3b56759c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=28-29

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

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

From kvn at openjdk.org  Thu Oct 23 17:17:01 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Oct 2025 17:17:01 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
In-Reply-To: <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
 <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
Message-ID: <HdVe4W_S6J7Wm6DlrLeOWHyU-ENSSdV4NBLOQd_-50k=.45c177e9-e7b4-4d8c-b270-d0c153a9d3a1@github.com>

On Wed, 15 Oct 2025 19:17:37 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>>> I'm not sure if you saw this because of the bot comments but I'm not able to reproduce the COH failure
>> 
>> @chadrako, I added test output to [8369150](https://bugs.openjdk.org/browse/JDK-8369150) bug report.
>> 
>> Do you unload old method after coping and let GC do it normal way?
>
>> Do you unload old method after coping and let GC do it normal way?
> 
> When an nmethod is relocated the old is marked not entrant. Then yes it is unloaded normally by the GC. The issue is most likely the GC deciding not to unload it for whatever reason. I'll see if there is a more deterministic way to test this

@chadrako what is status of this work. If you are struggling to reproduce [8369150](https://bugs.openjdk.org/browse/JDK-8369150) you can fix it separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3438176293

From duke at openjdk.org  Thu Oct 23 17:33:21 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 23 Oct 2025 17:33:21 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v2]
In-Reply-To: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
Message-ID: <6dX4hnm-wd-kZ-FVuZMe2RY0zAstL8x-eKjqCUnAhRI=.fdcbf683-03d7-4610-bd7e-650c94cae155@github.com>

> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
> 
> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
> 
> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
> 
> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
> 
> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC

Chad Rakoczy has updated the pull request incrementally with four additional commits since the last revision:

 - Fix requires
 - Reproblem list serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java
 - Compile for 30 seconds instead of 1024 methods
 - Fix requires

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27659/files
  - new: https://git.openjdk.org/jdk/pull/27659/files/6cbda05f..769800cb

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

  Stats: 52 lines in 6 files changed: 16 ins; 2 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/27659.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27659/head:pull/27659

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

From duke at openjdk.org  Thu Oct 23 17:33:23 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 23 Oct 2025 17:33:23 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v2]
In-Reply-To: <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
 <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
Message-ID: <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>

On Wed, 15 Oct 2025 19:17:37 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>>> I'm not sure if you saw this because of the bot comments but I'm not able to reproduce the COH failure
>> 
>> @chadrako, I added test output to [8369150](https://bugs.openjdk.org/browse/JDK-8369150) bug report.
>> 
>> Do you unload old method after coping and let GC do it normal way?
>
>> Do you unload old method after coping and let GC do it normal way?
> 
> When an nmethod is relocated the old is marked not entrant. Then yes it is unloaded normally by the GC. The issue is most likely the GC deciding not to unload it for whatever reason. I'll see if there is a more deterministic way to test this

> @chadrako what is status of this work. If you are struggling to reproduce [8369150](https://bugs.openjdk.org/browse/JDK-8369150) you can fix it separately.

I haven't been able to reproduce that failure. I'll reopen [8369150](https://bugs.openjdk.org/browse/JDK-8369150) so it can be completed separately

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3438252118

From pchilanomate at openjdk.org  Thu Oct 23 17:39:38 2025
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 23 Oct 2025 17:39:38 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Thanks for doing this cleanup. I only found some instances in comments where `lightweight` referred to the locking mode and not just the fast path, so the word should be removed rather than replaced with `fast`.

src/hotspot/share/oops/markWord.hpp line 215:

> 213:   ObjectMonitor* monitor() const {
> 214:     assert(has_monitor(), "check");
> 215:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");

Suggestion:

    assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

src/hotspot/share/oops/markWord.hpp line 241:

> 239:   }
> 240:   static markWord encode(ObjectMonitor* monitor) {
> 241:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");

Suggestion:

    assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

src/hotspot/share/runtime/objectMonitor.hpp line 164:

> 162:   // Because of frequent access, the metadata field is at offset zero (0).
> 163:   // Enforced by the assert() in metadata_addr().
> 164:   // * Fast locking with UseObjectMonitorTable:

Suggestion:

  // * Locking with UseObjectMonitorTable:

src/hotspot/share/runtime/objectMonitor.hpp line 166:

> 164:   // * Fast locking with UseObjectMonitorTable:
> 165:   //   Contains the _object's hashCode.
> 166:   // * * Fast locking without UseObjectMonitorTable:

Suggestion:

  // * Locking without UseObjectMonitorTable:

src/hotspot/share/runtime/objectMonitor.inline.hpp line 77:

> 75: 
> 76: inline markWord ObjectMonitor::header() const {
> 77:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");

Suggestion:

  assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

src/hotspot/share/runtime/objectMonitor.inline.hpp line 82:

> 80: 
> 81: inline void ObjectMonitor::set_header(markWord hdr) {
> 82:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");

Suggestion:

  assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

src/hotspot/share/runtime/objectMonitor.inline.hpp line 87:

> 85: 
> 86: inline intptr_t ObjectMonitor::hash() const {
> 87:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");

Suggestion:

  assert(UseObjectMonitorTable, "Only used by locking with OM table");

src/hotspot/share/runtime/objectMonitor.inline.hpp line 92:

> 90: 
> 91: inline void ObjectMonitor::set_hash(intptr_t hash) {
> 92:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");

Suggestion:

  assert(UseObjectMonitorTable, "Only used by locking with OM table");

src/hotspot/share/runtime/synchronizer.cpp line 648:

> 646:       // stability and then install the hash.
> 647:     } else {
> 648:       assert(!mark.is_unlocked() && !mark.is_fast_locked(), "invariant");

Note that `mark.monitor()` below already asserts `mark.has_monitor()` which is stronger.

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

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3371295012
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456141768
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456143321
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456146275
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456190353
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456194705
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456195722
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456201765
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456204642
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2456288423

From kvn at openjdk.org  Thu Oct 23 17:45:20 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Oct 2025 17:45:20 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v2]
In-Reply-To: <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
 <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
 <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>
Message-ID: <AxxZAgOsBEYEme0Vb0NlYCjdMzZUJFNThym7rQMNTgQ=.224ebb08-2c85-4750-956b-853b31b84d3f@github.com>

On Thu, 23 Oct 2025 17:30:27 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>>> Do you unload old method after coping and let GC do it normal way?
>> 
>> When an nmethod is relocated the old is marked not entrant. Then yes it is unloaded normally by the GC. The issue is most likely the GC deciding not to unload it for whatever reason. I'll see if there is a more deterministic way to test this
>
>> @chadrako what is status of this work. If you are struggling to reproduce [8369150](https://bugs.openjdk.org/browse/JDK-8369150) you can fix it separately.
> 
> I haven't been able to reproduce that failure. I'll reopen [8369150](https://bugs.openjdk.org/browse/JDK-8369150) so it can be completed separately

@chadrako, is PR ready for testing now?

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3438306723

From duke at openjdk.org  Thu Oct 23 18:47:24 2025
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 23 Oct 2025 18:47:24 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v2]
In-Reply-To: <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
 <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
 <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>
Message-ID: <ZnFSViO4R9Bcp_qJryLWdqG6KK6yQm19rQb93ydgE5M=.3513d7b9-e9c9-489f-9f5c-8a1f5ffd3b8f@github.com>

On Thu, 23 Oct 2025 17:30:27 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>>> Do you unload old method after coping and let GC do it normal way?
>> 
>> When an nmethod is relocated the old is marked not entrant. Then yes it is unloaded normally by the GC. The issue is most likely the GC deciding not to unload it for whatever reason. I'll see if there is a more deterministic way to test this
>
>> @chadrako what is status of this work. If you are struggling to reproduce [8369150](https://bugs.openjdk.org/browse/JDK-8369150) you can fix it separately.
> 
> I haven't been able to reproduce that failure. I'll reopen [8369150](https://bugs.openjdk.org/browse/JDK-8369150) so it can be completed separately

> @chadrako, is PR ready for testing now?

Yes

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3438589415

From kvn at openjdk.org  Thu Oct 23 18:59:48 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 23 Oct 2025 18:59:48 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v2]
In-Reply-To: <6dX4hnm-wd-kZ-FVuZMe2RY0zAstL8x-eKjqCUnAhRI=.fdcbf683-03d7-4610-bd7e-650c94cae155@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <6dX4hnm-wd-kZ-FVuZMe2RY0zAstL8x-eKjqCUnAhRI=.fdcbf683-03d7-4610-bd7e-650c94cae155@github.com>
Message-ID: <ntPbC0lwR04C3wkPagM3ygxK2J6BEDrJXNYOPSaO6e0=.3d492583-38ae-44d9-a224-57f26a1e29bb@github.com>

On Thu, 23 Oct 2025 17:33:21 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
>> 
>> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
>> 
>> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
>> 
>> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
>> 
>> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC
>
> Chad Rakoczy has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Fix requires
>  - Reproblem list serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java
>  - Compile for 30 seconds instead of 1024 methods
>  - Fix requires

I submitted testing

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3438643384

From eosterlund at openjdk.org  Thu Oct 23 19:15:29 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 23 Oct 2025 19:15:29 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v7]
In-Reply-To: <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <p48VQxedGtWu2RpqFk_cf7mgV7A0n5eKdZoFNuY81g0=.49a9e803-36bd-4d34-b7a6-060b684c2ba4@github.com>
 <VgQW8s38rrF5yqHOyiX9PysCuWD3jDfBvbBOMWwyaPM=.d44e4b83-c164-41ff-bbb9-d1f7179bc224@github.com>
 <hPuV5FcfClOPlMk6JJUQVEFI1phPV5l0ZhJpkZOgfug=.e2dfb67d-3fa1-4b00-aefd-f48ce20ea62d@github.com>
 <QeGK2OtCPyT7-I00aXq0sPu3lr9Sr7MFoGnPX7P8J8s=.c593690d-22f0-4a4c-aab0-0ab641e21a65@github.com>
Message-ID: <Crxlv9lOmgJCpSesWre55iAe5sxOykaewK7yVNEi7u4=.8074c95f-c4dc-49d9-acd3-8776d832954d@github.com>

On Thu, 23 Oct 2025 16:06:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > > Given that we know have support for CDS from all GCs is it time to replace all `INCLUDE_CDS_JAVA_HEAP` with just `INCLUDE_CDS`?
> 
> > 
> 
> > I think we could do that indeed. However, I would like that to be a follow-up cleanup, to avoid cluttering more files in this PR.
> 
> 
> 
> We have 
> 
> 
> 
> ```
> 
> #if INCLUDE_CDS && INCLUDE_G1GC && defined(_LP64)
> 
> #define INCLUDE_CDS_JAVA_HEAP 1
> 
> ```
> 
> 
> 
> So we need to make sure it works for 32 bit as well.

Does 32 bit really need CDS at all? Zero surely doesn't; it's 100x slower. Left we have 32 bit ARM which is seemingly on life support. But yeah either way - not  a decision for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3438689367

From kevinw at openjdk.org  Thu Oct 23 20:42:57 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 23 Oct 2025 20:42:57 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute [v2]
In-Reply-To: <ELbHByCRzbYuT-h_4DI2aT6byRpWAeHjAV97Jj_73uo=.03889f05-5b7e-45dd-a6c0-cac6011c4807@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
 <ELbHByCRzbYuT-h_4DI2aT6byRpWAeHjAV97Jj_73uo=.03889f05-5b7e-45dd-a6c0-cac6011c4807@github.com>
Message-ID: <7BTlWRF19fek9F1tke8-jOjjXd2LZAVmgOVal_2vLGg=.0e4c97a1-f174-4728-8bbe-e227a17987a3@github.com>

On Mon, 20 Oct 2025 01:23:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735 __GI_abort + 0x8b
>> 0x00007f50e1e01f33 ????????
>> 
>> 
>> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
>> 
>> 
>> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
>> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
>> => 0x00007f50e1e01f33: nop
>> End of assembler dump.
>> 
>> 
>> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
>> 
>> After this PR, you can see the right symbol as following:
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735      __GI_abort + 0x8b
>> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add fallback code to process DWARF with RIP-1 in Linux AMD64
>  - Revert "8369994: Mixed mode jhsdb jstack cannot resolve symbol with cold attribute"
>    
>    This reverts commit 570b65c6b56ba3378d4f532fa0874ff08ff18451.

(I had a look, I thought it might be simpler but yes do we need to retry resolving DWARF also?  I can look again soon.)

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3439062695

From ysuenaga at openjdk.org  Thu Oct 23 23:16:00 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 23 Oct 2025 23:16:00 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute [v2]
In-Reply-To: <7BTlWRF19fek9F1tke8-jOjjXd2LZAVmgOVal_2vLGg=.0e4c97a1-f174-4728-8bbe-e227a17987a3@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
 <ELbHByCRzbYuT-h_4DI2aT6byRpWAeHjAV97Jj_73uo=.03889f05-5b7e-45dd-a6c0-cac6011c4807@github.com>
 <7BTlWRF19fek9F1tke8-jOjjXd2LZAVmgOVal_2vLGg=.0e4c97a1-f174-4728-8bbe-e227a17987a3@github.com>
Message-ID: <g2C5hru4SB8atkk4yvPS4_7Kk3j4bCtE0LNa4P25E5Y=.27a7df17-d515-46d7-b179-12d15fab7d11@github.com>

On Thu, 23 Oct 2025 20:40:22 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> do we need to retry resolving DWARF also?

It does not need for symbol resolution, but it is necessary to continue unwinding.

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

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3439670691

From kvn at openjdk.org  Fri Oct 24 00:26:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Oct 2025 00:26:02 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v2]
In-Reply-To: <6dX4hnm-wd-kZ-FVuZMe2RY0zAstL8x-eKjqCUnAhRI=.fdcbf683-03d7-4610-bd7e-650c94cae155@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <6dX4hnm-wd-kZ-FVuZMe2RY0zAstL8x-eKjqCUnAhRI=.fdcbf683-03d7-4610-bd7e-650c94cae155@github.com>
Message-ID: <P8B3aRe0toJ_SRCBYx1EcgYHaxKKqbSAnG_pxQ32fwA=.004ad1ca-4ae9-4e40-8ca3-8cea0a0dcda6@github.com>

On Thu, 23 Oct 2025 17:33:21 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8369147](https://bugs.openjdk.org/browse/JDK-8369147)
>> 
>> Fixes tests added in [JDK-8316694](https://bugs.openjdk.org/browse/JDK-8316694)
>> 
>> `DeoptimizeRelocatedNMethod.java` and `RelocateNMethod.java` failed because they attempted to relocate nmethods to the `MethodProfiled` code heap which does not exist when `TieredCompilation` is false. Updated the tests to use `MethodNonProfiled` heap which exists regardless of `TieredCompilation`
>> 
>> `StressNMethodRelocation.java` runs for 60 seconds and also compiles 1024 methods with C2. This was causing the test to timeout if the compilation took too much time. Increasing the timeout to 5 minutes should give C2 enough time to compile the functions
>> 
>> `NMethodRelocationTest.java` runs using SerialGC which caused a multiple GC error when trying to run with another GC. Added a requires to force SerialGC
>
> Chad Rakoczy has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Fix requires
>  - Reproblem list serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java
>  - Compile for 30 seconds instead of 1024 methods
>  - Fix requires

Unfortunately all sub-tests with `-XX:+UseShenandoahGC` failed because Oracle JDK does not include this GC: 

Error occurred during initialization of VM
Option -XX:+UseShenandoahGC not supported

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3440046663

From kvn at openjdk.org  Fri Oct 24 00:33:02 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 24 Oct 2025 00:33:02 GMT
Subject: RFR: 8369147: Various issues with new tests added by JDK-8316694
 [v2]
In-Reply-To: <ZnFSViO4R9Bcp_qJryLWdqG6KK6yQm19rQb93ydgE5M=.3513d7b9-e9c9-489f-9f5c-8a1f5ffd3b8f@github.com>
References: <lxmbixdOJEIfpHk2lFzkM3K-JdgDE4LYlpjXt7qXEqM=.518a4059-3f9d-44ae-b13b-91108e7f3fcd@github.com>
 <8UVgF0vLaZhY7zvKWPBLXoU9p71SevknlPYC5LPsfCo=.8531cacc-ff26-42be-a517-88ff87628d29@github.com>
 <rOd4Y7hUtccWxehJUpm7HimJEXgst9XquSJTj5zRdw8=.e6e0899f-8ed3-4fb4-849e-9e33fac406fe@github.com>
 <mnFu9wc1vLjNU66pOFtE05RMIVIP954BWwxoPLpvP4k=.16023c35-4817-4e9d-b95e-aa23109bbdc2@github.com>
 <0ZFCDTQAFKjZ5XDtUXWsvC4v0lyot7Trdf3wlIxrb-M=.988407f3-6353-447a-98d6-f890b795fd1d@github.com>
 <qINS_i_B5rksUd7oS_POuzkNBce1LMEw3zBx5Ecntno=.87b90411-a7be-437c-97fa-6c2c1934a316@github.com>
 <ZnFSViO4R9Bcp_qJryLWdqG6KK6yQm19rQb93ydgE5M=.3513d7b9-e9c9-489f-9f5c-8a1f5ffd3b8f@github.com>
Message-ID: <04axkDv5tJbnZz4o8TYCU0g9l0NqtDYGMkxAAzdiCvs=.43dfa056-97b5-4e30-95f6-1835db991bd9@github.com>

On Thu, 23 Oct 2025 18:45:08 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>>> @chadrako what is status of this work. If you are struggling to reproduce [8369150](https://bugs.openjdk.org/browse/JDK-8369150) you can fix it separately.
>> 
>> I haven't been able to reproduce that failure. I'll reopen [8369150](https://bugs.openjdk.org/browse/JDK-8369150) so it can be completed separately
>
>> @chadrako, is PR ready for testing now?
> 
> Yes

@chadrako   I think my suggestion was not correct. We should revert back to your first changes for `@requires`.
Original code was correct and only `serviceability/jvmti/NMethodRelocation/NMethodRelocationTest.java` missed it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27659#issuecomment-3440078040

From fyang at openjdk.org  Fri Oct 24 01:20:02 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 Oct 2025 01:20:02 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
Message-ID: <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>

On Thu, 23 Oct 2025 08:38:05 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> @bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar Hi guys! This is the last PR in a series of PRs to obsolete the `LockingMode` flag and related code. So please please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance.

Hello, A simple tier1 test is good on linux-riscv64. I checked the riscv part and I only see in indentation issues as pointed out by @TheRealMDoerr.

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

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3440216009

From fyang at openjdk.org  Fri Oct 24 01:28:05 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 Oct 2025 01:28:05 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <VU0aXhIIV_c9P-QSAWP0hZMm9aNM1UsHrbsZbsKOy3A=.9041a0b4-1738-4264-a53d-b6829d685bd3@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
 <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
 <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>
 <1pCb9jVqE1g4rIHCQTyUNU3HX1mm_30MI0Ux9_WyBD8=.31174776-e691-445b-b288-ba97272e637a@github.com>
 <VU0aXhIIV_c9P-QSAWP0hZMm9aNM1UsHrbsZbsKOy3A=.9041a0b4-1738-4264-a53d-b6829d685bd3@github.com>
Message-ID: <-IavTMPm3hGAIFPYGYfO_H3-JtIrtfIsm_aRZkVlhsg=.1d7ffa01-9e29-4393-ae29-6a9b82b061bf@github.com>

On Thu, 23 Oct 2025 07:22:53 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Sure. This is what I got on my amd64 machine:
>> 
>> ```$ make test TEST="serviceability/sa/TestJhsdbJstackMixedWithXComp.java"```
>> 
>> [TestJhsdbJstackMixedWithXComp.jtr.txt](https://github.com/user-attachments/files/23091141/TestJhsdbJstackMixedWithXComp.jtr.txt)
>
> @RealFYang Thank you for sharing it!
> 
> I think it might be caused by binary difference, it is not caused by this PR at least. So I think we can go forward this PR, make sence?
> 
> Your .jtr file implies stack unwinding was failed from the function by libc in following:
> 
> ----------------- 2310034 -----------------
> "SteadyStateThread" #39 prio=5 tid=0x00007fd2600358a0 nid=2310034 waiting for monitor entry [0x00007fd2351f4000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
>    JavaThread state: _thread_blocked
> 0x00007fd267930f16      __futex_abstimed_wait_common + 0xc6
> ----------------- 2310033 -----------------
> "ForkJoinPool-1-worker-2" #38 daemon prio=5 tid=0x00007fd1ec006600 nid=2310033 runnable [0x00007fd2352f5000]
>    java.lang.Thread.State: RUNNABLE
>    JavaThread state: _thread_in_native
> 0x00007fd26797a545      __clock_nanosleep + 0x65
> 0x00007fd26797ee53      __GI___nanosleep + 0x13
> 
> 
> Native stack unwinding on Linux AMD64 depends on DWARF (in AArch64, it depends on FP (x29) yet).
> I downloaded and checked libc.so.6 in libc6-udeb_2.41-12_amd64.udeb, it has `.eh_frame` section which would be used by `DwarfParser`, but it does not have any symbols, and not have `.gnu_debuglink` ELF section. OTOH Fedora 43 which I confirmed to work has both symbols and `.gnu_debuglink`.
> 
> They are used for symbol resolution, not stack unwinding. However other difference(s) in binary might affect statck unwinding. Thus I think it is not a problem caused by this PR.

Hi, I am just wondering if there is a workaround for these platforms. Or can we simply skip this when testing on them? Say, if this depends on the availability of pstack, maybe we can add check for that then. Otherwise, we may introduce test noise for people who use them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2458277165

From kdnilsen at openjdk.org  Fri Oct 24 03:41:50 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 03:41:50 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v31]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <G9pq0QcX_t3_O_piD3HIbqfBhiVkZAhzhzAmO838WdQ=.148b7a66-ee59-4212-ae2a-6da19faad7cc@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  Rework implementation of CompressedClassSpaceSizeInJmapHeap.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/3b56759c..467e7514

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=29-30

  Stats: 27 lines in 1 file changed: 1 ins; 17 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From ysuenaga at openjdk.org  Fri Oct 24 07:11:02 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 24 Oct 2025 07:11:02 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <-IavTMPm3hGAIFPYGYfO_H3-JtIrtfIsm_aRZkVlhsg=.1d7ffa01-9e29-4393-ae29-6a9b82b061bf@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
 <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
 <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>
 <1pCb9jVqE1g4rIHCQTyUNU3HX1mm_30MI0Ux9_WyBD8=.31174776-e691-445b-b288-ba97272e637a@github.com>
 <VU0aXhIIV_c9P-QSAWP0hZMm9aNM1UsHrbsZbsKOy3A=.9041a0b4-1738-4264-a53d-b6829d685bd3@github.com>
 <-IavTMPm3hGAIFPYGYfO_H3-JtIrtfIsm_aRZkVlhsg=.1d7ffa01-9e29-4393-ae29-6a9b82b061bf@github.com>
Message-ID: <jSS_0F3errESVqMQLqLBa2bCmwXN3fZlnmpr1qF0zOc=.3aa69838-bfca-402b-92d8-f57925cea9d9@github.com>

On Fri, 24 Oct 2025 01:25:06 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> @RealFYang Thank you for sharing it!
>> 
>> I think it might be caused by binary difference, it is not caused by this PR at least. So I think we can go forward this PR, make sence?
>> 
>> Your .jtr file implies stack unwinding was failed from the function by libc in following:
>> 
>> ----------------- 2310034 -----------------
>> "SteadyStateThread" #39 prio=5 tid=0x00007fd2600358a0 nid=2310034 waiting for monitor entry [0x00007fd2351f4000]
>>    java.lang.Thread.State: BLOCKED (on object monitor)
>>    JavaThread state: _thread_blocked
>> 0x00007fd267930f16      __futex_abstimed_wait_common + 0xc6
>> ----------------- 2310033 -----------------
>> "ForkJoinPool-1-worker-2" #38 daemon prio=5 tid=0x00007fd1ec006600 nid=2310033 runnable [0x00007fd2352f5000]
>>    java.lang.Thread.State: RUNNABLE
>>    JavaThread state: _thread_in_native
>> 0x00007fd26797a545      __clock_nanosleep + 0x65
>> 0x00007fd26797ee53      __GI___nanosleep + 0x13
>> 
>> 
>> Native stack unwinding on Linux AMD64 depends on DWARF (in AArch64, it depends on FP (x29) yet).
>> I downloaded and checked libc.so.6 in libc6-udeb_2.41-12_amd64.udeb, it has `.eh_frame` section which would be used by `DwarfParser`, but it does not have any symbols, and not have `.gnu_debuglink` ELF section. OTOH Fedora 43 which I confirmed to work has both symbols and `.gnu_debuglink`.
>> 
>> They are used for symbol resolution, not stack unwinding. However other difference(s) in binary might affect statck unwinding. Thus I think it is not a problem caused by this PR.
>
> Hi, I am just wondering if there is a workaround for these platforms. Or can we simply skip this when testing on them? Say, if this depends on the availability of pstack, maybe we can add check for that then. Otherwise, we may introduce test noise for people who use them.

I could reproduce the problem not only Ubuntu 22.04 but also 23.04 . However it did not happen on Ubuntu 24.04 .
According to your report, the problem would happen on AArch64, it implies the problem is not in DWARF parser only. (DWARF parser is only available on Linux AMD64 so far)

AFAICS stack unwinding would fail from the function in glibc (on Ubuntu 22.04 and 23.04 at least), so I suspect something wrong in glibc binary and/or behavior and/or compiler options on Ubuntu. but I'm not sure.

I checked glibc version from `gnu_get_libc_version()`. "2.37" is returned on Ubuntu 23.04, and "2.39" is returned on Ubuntu 24.04 . So I think it can be `gnu_get_libc_version()` with FFM at first of the test, then the test is skipped if it runs on glibc 2.38 or earlier. Is it ok?

I grep'ed test directory with "mixed", I found another tests (TestJhsdbJstackMixed.java, TestJhsdbJstackPrintVMLocks.java). I will add glibc check to them as another ticket if this solution is ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2459103358

From ysuenaga at openjdk.org  Fri Oct 24 07:29:03 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 24 Oct 2025 07:29:03 GMT
Subject: RFR: 8369994: Mixed mode jhsdb jstack cannot resolve symbol with
 cold attribute [v2]
In-Reply-To: <ELbHByCRzbYuT-h_4DI2aT6byRpWAeHjAV97Jj_73uo=.03889f05-5b7e-45dd-a6c0-cac6011c4807@github.com>
References: <3BfI3hqINcYqLrOYQ1ohvsdpUo6dqgznggJp9XWftqw=.c52178f3-c963-41cf-bd07-504de5982824@github.com>
 <ELbHByCRzbYuT-h_4DI2aT6byRpWAeHjAV97Jj_73uo=.03889f05-5b7e-45dd-a6c0-cac6011c4807@github.com>
Message-ID: <BrP0AflbQNgTCEXx71fzZvWgKVkw_cLOMzJ20WIQ3nY=.9bf6dcb4-ee36-4e56-98fa-4425a503494c@github.com>

On Mon, 20 Oct 2025 01:23:45 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> `jhsdb jstack --mixed` with coredump cannot resolve function symbol which has `.cold` attribute.
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735 __GI_abort + 0x8b
>> 0x00007f50e1e01f33 ????????
>> 
>> 
>> 0x7f50e1e01f33 was `os::abort(bool, void const*, void const*) [clone .cold]` and I could see it in GDB. However it has `.cold` suffix, it means the code has been relocated as ["cold" function](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-cold-function-attribute). In GDB, we can see the code in another area from function body as following:
>> 
>> 
>> (gdb) disas 0x7f50e1e01f2e, 0x7f50e1e01f34
>> Dump of assembler code from 0x7f50e1e01f2e to 0x7f50e1e01f34:
>>    0x00007f50e1e01f2e <_ZN2os5abortEbPKvS1_.cold+0>: call 0x7f50e1e01010 <abort at plt>
>> => 0x00007f50e1e01f33: nop
>> End of assembler dump.
>> 
>> 
>> libsaproc.so checks address range to resolve symbol whether the address is in between `start` and `start + size - 1`. As you can see in assembler dump, the code in `.cold` section is `call` instruction, thus IP points next `nop`, thus we should allow address range between `start` and `start + size`.
>> 
>> After this PR, you can see the right symbol as following:
>> 
>> 
>> ----------------- 120485 -----------------
>> "Thread-0" #24 prio=5 tid=0x00007f50dc1aa7c0 nid=120485 waiting on condition [0x00007f50c0d1a000]
>>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>>    JavaThread state: _thread_blocked
>> 0x00007f50e4710735      __GI_abort + 0x8b
>> 0x00007f50e1e01f33      os::abort(bool, void const*, void const*) [clone .cold] + 0x5
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add fallback code to process DWARF with RIP-1 in Linux AMD64
>  - Revert "8369994: Mixed mode jhsdb jstack cannot resolve symbol with cold attribute"
>    
>    This reverts commit 570b65c6b56ba3378d4f532fa0874ff08ff18451.

I agree to separate issues symbol resolution and stack unwinding if it is better.

As I said before, my goal is to unwind all of call frames in `jhsdb jstack --mixed` without any unknown symbols.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27846#issuecomment-3441509573

From amitkumar at openjdk.org  Fri Oct 24 07:43:08 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 24 Oct 2025 07:43:08 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
 <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>
Message-ID: <NFB9895L92VCTapIUWd1GFphbxZhaJaj2GliigkCZzU=.1d5180fd-b658-4c39-8f9a-b9e8a3c85e73@github.com>

On Fri, 24 Oct 2025 01:16:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

> @bulasevich, @TheRealMDoerr, @RealFYang, @offamitkumar Hi guys! This is the last PR in a series of PRs to obsolete the `LockingMode` flag and related code. So please please grab a copy, run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance.

Hi, I ran tier1 and seems like on s390 everything is good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3441568007

From sspitsyn at openjdk.org  Fri Oct 24 09:51:13 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 24 Oct 2025 09:51:13 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v6]
In-Reply-To: <anWMc2hYAP-wUiRwMwBiLfbODelXyb5DcGvOSUkMXJY=.7d2c062b-94f3-4bfc-bdb4-fd66c87df2ab@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
 <anWMc2hYAP-wUiRwMwBiLfbODelXyb5DcGvOSUkMXJY=.7d2c062b-94f3-4bfc-bdb4-fd66c87df2ab@github.com>
Message-ID: <BCsinrGCN-HQH8onNxM3i6vDzy3fHon9kzj-T1sdf5A=.cd4e215a-8ef1-4b68-a085-674d1741f108@github.com>

On Wed, 22 Oct 2025 05:28:37 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
>> 
>> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
>> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
>> 
>> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
>> 
>> The location should be zero for JNI access.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   the updated comments

The fix looks pretty good. I've posted several nits though.

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/FieldsEventsFromJNI.java line 48:

> 46:     public static void main(String[] args) throws InterruptedException {
> 47:         System.loadLibrary("FieldsEventsFromJNI");
> 48:         FieldsEventsFromJNI c = new FieldsEventsFromJNI();

Nit: Better to give the local some meaningful name instead of `c`. :)

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/FieldsEventsFromJNI.java line 62:

> 60:         synchronized(lock) {
> 61:             anotherThread.start();
> 62:             while(!isAnotherThreadStarted) {

Nit: Missed space after `while` and `synchronized` at lines: 53, 56, 60 and 62.

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/libFieldsEventsFromJNI.cpp line 135:

> 133:     fatal(jni, "No class found");
> 134:   }
> 135:   jfieldID fieldToRead = jni->GetFieldID(cls, "accessField", "Ljava/lang/String;");

Nit: It is better to define a constant for the field name `"accessField"`. Also it used in two places at lines: 52 and 135. The same is true for the `"SetFieldAccessWatch"`.

test/hotspot/jtreg/serviceability/jvmti/events/FieldAccess/FieldsEventsFromJNI/libFieldsEventsFromJNI.cpp line 193:

> 191:   check_jvmti_error(err, "SetEventNotificationMode");
> 192: 
> 193:   if (modify_cnt != isEventExpected) {

Nit: Comparing an `int` with a jboolean`. The same is at line 160. I'd suggest to pass expected number of events instead of jboolean. Then it is better to define `access_cnt` and `modify_cnt` as `jint`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27584#pullrequestreview-3375321998
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2459466954
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2459470649
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2459533264
PR Review Comment: https://git.openjdk.org/jdk/pull/27584#discussion_r2459543963

From eosterlund at openjdk.org  Fri Oct 24 10:44:53 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 24 Oct 2025 10:44:53 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v9]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <3oUWkJvh73VUnHcycK-2MahguUU_zwxv-xvfztvZg9M=.1edcb4ef-dd2d-41da-b33f-77cfbd55f1cb@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request incrementally with one additional commit since the last revision:

  Missing unlock diagnostic VM options, and remove unintended comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27732/files
  - new: https://git.openjdk.org/jdk/pull/27732/files/99726c72..b355e036

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=07-08

  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From coleenp at openjdk.org  Fri Oct 24 11:19:04 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 24 Oct 2025 11:19:04 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>

On Tue, 21 Oct 2025 13:11:45 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Never say "last" cleanup.  The renaming to remove "lightweight" looks good.  I wasn't sure if we wanted to keep that name or not.  There's a lightweight NMT coming so this won't be confused with that anymore.  I guess that's good.

src/hotspot/share/runtime/synchronizer.cpp line 1454:

> 1452: // -----------------------------------------------------------------------------
> 1453: // ConcurrentHashTable storing links from objects to ObjectMonitors
> 1454: class ObjectMonitorTable : AllStatic {

I guess after looking at this, it made sense to combine the lightweightSynchronizer code into synchronizer.cpp (should be ObjectSynchronizer.hpp/cpp).  I wonder if the OM table code could be split out into its own file objectMontitorTable.hpp/cpp.  I feel like synchronzer.hpp/cpp again does too many different things.

src/hotspot/share/runtime/synchronizer.inline.hpp line 40:

> 38:     return read_monitor(mark);
> 39:   } else {
> 40:     return ObjectSynchronizer::get_monitor_from_table(current, obj);

I don't think there's a need for this file anymore.  read_monitor is mostly called inside synchronizer.cpp, so it can be inlined there.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27915#pullrequestreview-3375815186
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2459848893
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2459863994

From duke at openjdk.org  Fri Oct 24 12:19:52 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 12:19:52 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v6]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <zPwIZTo2vL1vSn_JuUqmxRCcC0KqvRpnwQdbz0JweDQ=.b98781e8-de09-4d2b-b81b-5fc36a8d4949@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Add default implementation and elaborate API docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/a188df0b..f8a9f7a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=04-05

  Stats: 20 lines in 1 file changed: 12 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Fri Oct 24 12:37:02 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 12:37:02 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v7]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix link for getProcessCpuTime

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/f8a9f7a3..08af7b51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From bulasevich at openjdk.org  Fri Oct 24 13:26:06 2025
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Fri, 24 Oct 2025 13:26:06 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <NFB9895L92VCTapIUWd1GFphbxZhaJaj2GliigkCZzU=.1d5180fd-b658-4c39-8f9a-b9e8a3c85e73@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8ZPciN2yFvdsAzAGd2YwM6aT463fmp8CGx6-m-7Sfp8=.6b96b17f-3ef8-4280-8679-0aaa6861f6fe@github.com>
 <_qtN4e0ynUi2lyZE1SuBE4PyN2WIgGXdUe5L5FNvdOI=.a96026f0-3521-40ab-bd76-594345375bcd@github.com>
 <NFB9895L92VCTapIUWd1GFphbxZhaJaj2GliigkCZzU=.1d5180fd-b658-4c39-8f9a-b9e8a3c85e73@github.com>
Message-ID: <LAaJOKIUZfH6pVF5J-g4M-8YHydNcOabkra7ScVE1Rk=.fbd1fa1e-dfc3-40bf-a5f9-f9f5c90cde36@github.com>

On Fri, 24 Oct 2025 07:39:56 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> run it on your favorite platform, and tell me if there's anything wrong with it. Thanks in advance.

Hi, tier1 runs clean on ARM32. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3443145056

From fbredberg at openjdk.org  Fri Oct 24 13:49:09 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 13:49:09 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
Message-ID: <vDEwDKY6qM4s4TsjY_0xXTxqDgDvbrukiQelBuH1QdA=.43cb268a-e867-4cf4-a592-c9b671e4423a@github.com>

On Thu, 23 Oct 2025 17:29:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> src/hotspot/share/runtime/synchronizer.cpp line 648:
> 
>> 646:       // stability and then install the hash.
>> 647:     } else {
>> 648:       assert(!mark.is_unlocked() && !mark.is_fast_locked(), "invariant");
> 
> Note that `mark.monitor()` below already asserts `mark.has_monitor()` which is stronger.

Good point, but I still like to keep the `assert()` on 648 for clarity. Would you rather see it removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460563344

From fbredberg at openjdk.org  Fri Oct 24 13:55:03 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 13:55:03 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
Message-ID: <00xzxB3fxjSbmCZCQCu_ZEClnyxq2yfPfF-9SKJXoIc=.b45bec0f-164d-4604-87e2-d69ce072533b@github.com>

On Fri, 24 Oct 2025 11:10:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> src/hotspot/share/runtime/synchronizer.cpp line 1454:
> 
>> 1452: // -----------------------------------------------------------------------------
>> 1453: // ConcurrentHashTable storing links from objects to ObjectMonitors
>> 1454: class ObjectMonitorTable : AllStatic {
> 
> I guess after looking at this, it made sense to combine the lightweightSynchronizer code into synchronizer.cpp (should be ObjectSynchronizer.hpp/cpp).  I wonder if the OM table code could be split out into its own file objectMontitorTable.hpp/cpp.  I feel like synchronzer.hpp/cpp again does too many different things.

Since we are currently investigating the OM table elseware (see: [JDK-8365493](https://bugs.openjdk.org/browse/JDK-8365493)) I wore for not doing any OM table refactoring in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460595360

From fbredberg at openjdk.org  Fri Oct 24 14:01:29 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:01:29 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <8Rwv4Cs35RINL9l1YVBYNZmbc6YZNE3C5lO21ACBR3c=.004cf158-a586-4bb2-b22b-81df349b1bdd@github.com>
Message-ID: <Fwfv1pejLzs-l_qn0qS3yyqJUyxOwcLroA9ckX0iP-A=.0b224d30-a1d4-4ad0-82aa-edf453cf6e96@github.com>

On Fri, 24 Oct 2025 11:14:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> src/hotspot/share/runtime/synchronizer.inline.hpp line 40:
> 
>> 38:     return read_monitor(mark);
>> 39:   } else {
>> 40:     return ObjectSynchronizer::get_monitor_from_table(current, obj);
> 
> I don't think there's a need for this file anymore.  read_monitor is mostly called inside synchronizer.cpp, so it can be inlined there.

Would you want me to do that in this PR? Or should I create a new RFE for that, just to acknowledge the fact that one should never say "last" cleanup. :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460616703

From fbredberg at openjdk.org  Fri Oct 24 14:20:36 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:20:36 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
Message-ID: <U7TfD73E7MuI0ZWRHzkbcGi2bXbYeBRTG7Re6Xk7H4I=.b8129f23-324e-45e4-8734-d32f9935aecb@github.com>

> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
> 
> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
> 
> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
> 
> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.

Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:

  Update after review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27915/files
  - new: https://git.openjdk.org/jdk/pull/27915/files/993d6137..6e331721

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27915&range=00-01

  Stats: 43 lines in 22 files changed: 4 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/27915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27915/head:pull/27915

PR: https://git.openjdk.org/jdk/pull/27915

From fbredberg at openjdk.org  Fri Oct 24 14:20:43 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:20:43 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
 [v2]
In-Reply-To: <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <6FVMNds2K-oyy1vIdh1E7fx7ex2uk1y17gCqAyStIrA=.9946f8c0-3374-4d9d-8407-36dfa777d563@github.com>
Message-ID: <613im2U7u_eH4USMM73aU46Gbm9-OxTe8EQmF43HOiE=.6930771f-c863-4036-8b2b-fe4eb352051f@github.com>

On Thu, 23 Oct 2025 17:07:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update after review
>
> src/hotspot/share/oops/markWord.hpp line 215:
> 
>> 213:   ObjectMonitor* monitor() const {
>> 214:     assert(has_monitor(), "check");
>> 215:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");
> 
> Suggestion:
> 
>     assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

Fixed

> src/hotspot/share/oops/markWord.hpp line 241:
> 
>> 239:   }
>> 240:   static markWord encode(ObjectMonitor* monitor) {
>> 241:     assert(!UseObjectMonitorTable, "Fast locking with OM table does not use markWord for monitors");
> 
> Suggestion:
> 
>     assert(!UseObjectMonitorTable, "Locking with OM table does not use markWord for monitors");

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 164:
> 
>> 162:   // Because of frequent access, the metadata field is at offset zero (0).
>> 163:   // Enforced by the assert() in metadata_addr().
>> 164:   // * Fast locking with UseObjectMonitorTable:
> 
> Suggestion:
> 
>   // * Locking with UseObjectMonitorTable:

Fixed

> src/hotspot/share/runtime/objectMonitor.hpp line 166:
> 
>> 164:   // * Fast locking with UseObjectMonitorTable:
>> 165:   //   Contains the _object's hashCode.
>> 166:   // * * Fast locking without UseObjectMonitorTable:
> 
> Suggestion:
> 
>   // * Locking without UseObjectMonitorTable:

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 77:
> 
>> 75: 
>> 76: inline markWord ObjectMonitor::header() const {
>> 77:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");
> 
> Suggestion:
> 
>   assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 82:
> 
>> 80: 
>> 81: inline void ObjectMonitor::set_header(markWord hdr) {
>> 82:   assert(!UseObjectMonitorTable, "Fast locking with OM table does not use header");
> 
> Suggestion:
> 
>   assert(!UseObjectMonitorTable, "Locking with OM table does not use header");

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 87:
> 
>> 85: 
>> 86: inline intptr_t ObjectMonitor::hash() const {
>> 87:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");
> 
> Suggestion:
> 
>   assert(UseObjectMonitorTable, "Only used by locking with OM table");

Fixed

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 92:
> 
>> 90: 
>> 91: inline void ObjectMonitor::set_hash(intptr_t hash) {
>> 92:   assert(UseObjectMonitorTable, "Only used by fast locking with OM table");
> 
> Suggestion:
> 
>   assert(UseObjectMonitorTable, "Only used by locking with OM table");

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460715777
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460716434
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460717622
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460718167
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460718815
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460719494
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460722858
PR Review Comment: https://git.openjdk.org/jdk/pull/27915#discussion_r2460721685

From fbredberg at openjdk.org  Fri Oct 24 14:28:39 2025
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 24 Oct 2025 14:28:39 GMT
Subject: RFR: 8367982: Unify ObjectSynchronizer and LightweightSynchronizer
In-Reply-To: <B-c0Ef2m7mIjRjbjIejJ6GXiezMjdPSRp-XqRt0QlY0=.9c07a6d7-471b-4a71-b5cc-973a4d4d9131@github.com>
References: <QrYHibFKDyY-9kjlNsoCtdisa5vruLQKUbEiP3_OJIE=.4721509d-5ed9-4bf8-b3c0-3167e8891003@github.com>
 <B-c0Ef2m7mIjRjbjIejJ6GXiezMjdPSRp-XqRt0QlY0=.9c07a6d7-471b-4a71-b5cc-973a4d4d9131@github.com>
Message-ID: <0fBkUHRtlrowvXXkSzerYvd5KrlwF-acFyH0af9mbXU=.0d75de36-208e-4582-80d4-c47537f6e385@github.com>

On Thu, 23 Oct 2025 12:06:28 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> This is the last PR in a series of PRs (see: [JDK-8344261](https://bugs.openjdk.org/browse/JDK-8344261)) to obsolete the LockingMode flag and related code.
>> 
>> The main focus is to to unify `ObjectSynchronizer` and `LightweightSynchronizer`.
>> There used to be a number of "dispatch functions" to redirect calls depending on the setting of the `LockingMode` flag.
>> Since we now only have lightweight locking, there is no longer any need for those dispatch functions, so I removed them.
>> To remove the dispatch functions I renamed the corresponding lightweight functions and call them directly.
>> This ultimately led me to remove "lightweight" from the function names and go back to "fast" instead, just to avoid having some with, and some without the "lightweight" part of the name.
>> 
>> This PR also include a small simplification of `ObjectSynchronizer::FastHashCode`.
>> 
>> Tested tier1-7 (on supported platforms) without seeing any problems that can be traced to this code change.
>> All other platforms (`arm`, `ppc`, `riscv`, `s390`) has been sanity checked using QEMU.
>
> Thanks for cleaning this up on all platforms! Works on PPC64.
> Indentation could be improved at many places where the next line was aligned (all platforms and shared code).

@TheRealMDoerr, @RealFYang 
> Indentation could be improved at many places where the next line was aligned (all platforms and shared code).

Oops, my bad. Guess this what you end up with when you use `bash`, `grep -r` and `sed` to seek out and remove "lightweight" from a source tree, and then check the result using old Un*x style `diff -w`. I think all the faulty indentation stuff is fixed now, and yes I did check with "new" style `git diff` to see the surrounding lines.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27915#issuecomment-3443454592

From fyang at openjdk.org  Fri Oct 24 15:05:20 2025
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 24 Oct 2025 15:05:20 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <jSS_0F3errESVqMQLqLBa2bCmwXN3fZlnmpr1qF0zOc=.3aa69838-bfca-402b-92d8-f57925cea9d9@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
 <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
 <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>
 <1pCb9jVqE1g4rIHCQTyUNU3HX1mm_30MI0Ux9_WyBD8=.31174776-e691-445b-b288-ba97272e637a@github.com>
 <VU0aXhIIV_c9P-QSAWP0hZMm9aNM1UsHrbsZbsKOy3A=.9041a0b4-1738-4264-a53d-b6829d685bd3@github.com>
 <-IavTMPm3hGAIFPYGYfO_H3-JtIrtfIsm_aRZkVlhsg=.1d7ffa01-9e29-4393-ae29-6a9b82b061bf@github.com>
 <jSS_0F3errESVqMQLqLBa2bCmwXN3fZlnmpr1qF0zOc=.3aa69838-bfca-402b-92d8-f57925cea9d9@github.com>
Message-ID: <Z6eMslS_-h_ZW35HOLVeyDkguCTBpNxhi9uvkmUvjOw=.7059f3bd-1f7e-4e30-b737-3d18d776fbe4@github.com>

On Fri, 24 Oct 2025 07:08:08 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> Hi, I am just wondering if there is a workaround for these platforms. Or can we simply skip this when testing on them? Say, if this depends on the availability of pstack, maybe we can add check for that then. Otherwise, we may introduce test noise for people who use them.
>
> I could reproduce the problem not only Ubuntu 22.04 but also 23.04 . However it did not happen on Ubuntu 24.04 .
> According to your report, the problem would happen on AArch64, it implies the problem is not in DWARF parser only. (DWARF parser is only available on Linux AMD64 so far)
> 
> AFAICS stack unwinding would fail from the function in glibc (on Ubuntu 22.04 and 23.04 at least), so I suspect something wrong in glibc binary and/or behavior and/or compiler options on Ubuntu. but I'm not sure.
> 
> I checked glibc version from `gnu_get_libc_version()`. "2.37" is returned on Ubuntu 23.04, and "2.39" is returned on Ubuntu 24.04 . So I think it can be `gnu_get_libc_version()` with FFM at first of the test, then the test is skipped if it runs on glibc 2.38 or earlier. Is it ok?
> 
> I grep'ed test directory with "mixed", I found another tests (TestJhsdbJstackMixed.java, TestJhsdbJstackPrintVMLocks.java). I will add glibc check to them as another ticket if this solution is ok.

I am not sure about the glibc version as I don't know much about the differences among these distributions.
But it works for me if you want to fix all the affected tests in another PR. Thanks for considering that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2460933106

From alanb at openjdk.org  Fri Oct 24 15:32:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Oct 2025 15:32:33 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v7]
In-Reply-To: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
Message-ID: <ZMiU3uHab3Jhk8YAuMkt2ukJpDzyo4xpkvfFUtduKEA=.45ea1821-d663-4dae-8139-682960aeb4a7@github.com>

On Fri, 24 Oct 2025 12:37:02 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link for getProcessCpuTime

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 274:

> 272:      * spent in garbage collection.
> 273:      *
> 274:      * <p> This is the CPU time used by all garbage collection

Starting this paragraph with "This is the CPU time ..." is a bit awkward. Can you try "The time spent in spent in garbage collection (GC) is the CPU time ...".

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 289:

> 287:      * in garbage collection is highly implementation dependent.
> 288:      * In the HotSpot Virtual Machine implementation reported
> 289:      * time will include relevant implementation-specific details such

"In the HotSpot Virtual Machine implementation reported time will include".  A suggestion to improve this is to change it to "In the HotSpot Virtual Machine, this time includes.."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2461014442
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2461027518

From duke at openjdk.org  Fri Oct 24 18:27:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 18:27:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v8]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Review fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/08af7b51..5d360f45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=06-07

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Fri Oct 24 18:27:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 18:27:47 GMT
Subject: RFR: 8368527: JMX: Add an MXBeans method to query GC CPU time [v7]
In-Reply-To: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
Message-ID: <tmLI6jE_Wa1z0p5h5CYHSoOA1So-SR0Q4A6vD2n3Tvk=.e3d1e614-9d7f-42d7-9f89-9c55d3cc016f@github.com>

On Fri, 24 Oct 2025 12:37:02 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link for getProcessCpuTime

Thanks for the feedback. I addressed the above and ensured consistent usage of GC throughout.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3444369903

From kdnilsen at openjdk.org  Fri Oct 24 19:50:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 19:50:31 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v32]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <O3qsOVMs_LTS_2KjXDiXLpI_622FNnFaWdtCU5ceLas=.308063f4-c280-484a-844b-ce7b8b332a4c@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 154 commits:

 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - Rework implementation of CompressedClassSpaceSizeInJmapHeap.java
 - fix errors in CompressedClassSpaceSizeInJmapHeap.java
 - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
 - Add sleep to CompressedClassSpaceSizeInJmapHeap.java test
 - Fix up vmstructs and other infrastructure for jmap heap dump
 - After initialization, check for SoftMaxHeapSize changed by constraints enforcement
 - clamp SoftMaxHeapSize during initialization
 - revert change to SoftMaxHeapSizeConstraintFunc
 - fix anothr override declaration
 - ... and 144 more: https://git.openjdk.org/jdk/compare/97e5ac6e...abf9b1f8

-------------

Changes: https://git.openjdk.org/jdk/pull/26867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=31
  Stats: 3529 lines in 44 files changed: 2120 ins; 1005 del; 404 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From eosterlund at openjdk.org  Fri Oct 24 20:11:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 24 Oct 2025 20:11:27 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v10]
In-Reply-To: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
Message-ID: <WWEn55PY-r6nrUD__Pk788lyspszX1BoL5lLCCPaYOY=.5b2026eb-a03d-4d01-a577-9b1d25eacca5@github.com>

> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
> 
> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
> 
> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
> 
> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
> 
> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
> 
> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the order they are laid out in...

Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:

 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Missing unlock diagnostic VM options, and remove unintended comment
 - Fix for minimal
 - Change streaming/mapping states to be binary instead of tri states
 - Clean up VMProps
 - Make AOTStreamableObjects diagnostic
 - Test polishing
 - Merge branch 'master' into 8326035_JEP_object_streaming_v6
 - Test fix
 - move exception marks outside locks
 - ... and 12 more: https://git.openjdk.org/jdk/compare/97e5ac6e...3d771ca2

-------------

Changes: https://git.openjdk.org/jdk/pull/27732/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27732&range=09
  Stats: 8737 lines in 111 files changed: 5928 ins; 2349 del; 460 mod
  Patch: https://git.openjdk.org/jdk/pull/27732.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27732/head:pull/27732

PR: https://git.openjdk.org/jdk/pull/27732

From lmesnik at openjdk.org  Fri Oct 24 20:26:28 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Oct 2025 20:26:28 GMT
Subject: RFR: 8370636: com/sun/jdi/TwoThreadsTest.java should wait for
 completion of all threads
Message-ID: <EhmvvLRP_Wn5V9UtYwoN-1yt-WWgScrT7gnon7ExxRg=.0ff62f59-a89a-4866-b050-3d77ef7ef0ce@github.com>

Test 
com/sun/jdi/TwoThreadsTest.java 
start new threads using DebuggeeWrapper.newThread()
and exit immediately.

It is needed to jon() threads so test really works for virtual threads.

I looked on other threads that use DebuggeeWrapper.newThread(). Seems most of them already updated to join spawned threads.

Tested by running test on all platfrom with and wihtout virtual threads.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/27982/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27982&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370636
  Stats: 8 lines in 1 file changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27982/head:pull/27982

PR: https://git.openjdk.org/jdk/pull/27982

From kdnilsen at openjdk.org  Fri Oct 24 20:58:17 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 20:58:17 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v32]
In-Reply-To: <O3qsOVMs_LTS_2KjXDiXLpI_622FNnFaWdtCU5ceLas=.308063f4-c280-484a-844b-ce7b8b332a4c@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <O3qsOVMs_LTS_2KjXDiXLpI_622FNnFaWdtCU5ceLas=.308063f4-c280-484a-844b-ce7b8b332a4c@github.com>
Message-ID: <znIq7rs0fgc4sIApy_pkytEmlBNGBQOz-VOmO75zWsU=.4f9edf0e-8e15-4657-ae54-aeb860a7091d@github.com>

On Fri, 24 Oct 2025 19:50:31 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 154 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
>  - Rework implementation of CompressedClassSpaceSizeInJmapHeap.java
>  - fix errors in CompressedClassSpaceSizeInJmapHeap.java
>  - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
>  - Add sleep to CompressedClassSpaceSizeInJmapHeap.java test
>  - Fix up vmstructs and other infrastructure for jmap heap dump
>  - After initialization, check for SoftMaxHeapSize changed by constraints enforcement
>  - clamp SoftMaxHeapSize during initialization
>  - revert change to SoftMaxHeapSizeConstraintFunc
>  - fix anothr override declaration
>  - ... and 144 more: https://git.openjdk.org/jdk/compare/97e5ac6e...abf9b1f8

> I'm not convinced the change above to move the constraints check sooner is needed in order to use the value of SoftMaxHeapSize in ShenandoahHeap::initialize().
> 
> What's the error you see without this change?

I did some testing after reverting my change to the shared code, and I wasn't able to identify exactly how this change relates to particular regression failures.   I've committed new changes to mitigate the issues without changing shared code:

1. Inside ShenandoahHeap::initialize(), we clamp the assignment to _soft_max_size between min_capacity() and max_capacity()
2. In ShenandoahHeap::post_initialize(), we check_soft_max_changed().  This will change the value of _soft_max_size if the current value of SoftMaxHeapSize, which has now had its constraints enforced, differs from the current value of _soft_max_size.  Constraints are enforced following initialize() but before post_initialize().

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26867#issuecomment-3444885624

From wkemper at openjdk.org  Fri Oct 24 21:13:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 21:13:13 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v31]
In-Reply-To: <G9pq0QcX_t3_O_piD3HIbqfBhiVkZAhzhzAmO838WdQ=.148b7a66-ee59-4212-ae2a-6da19faad7cc@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <G9pq0QcX_t3_O_piD3HIbqfBhiVkZAhzhzAmO838WdQ=.148b7a66-ee59-4212-ae2a-6da19faad7cc@github.com>
Message-ID: <AbjXE8V8V5ifr4fuy2XjtPaxtFrOvEF2DpOKnRjDzW0=.0920ab05-9847-4660-82ac-1ffd5145f90b@github.com>

On Fri, 24 Oct 2025 03:41:50 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
>> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
>> 
>> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
>> 
>> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rework implementation of CompressedClassSpaceSizeInJmapHeap.java

test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java line 78:

> 76:         do {
> 77:             exitValue = run(pb);
> 78:         } while ((exitValue != 0) && (allowed_retries-- > 0));

Just a nit, but the other variables here use Java's camel case convention, so should probably have `allowedRetries`, not `allowed_retries`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26867#discussion_r2461988687

From lmesnik at openjdk.org  Fri Oct 24 23:32:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 24 Oct 2025 23:32:48 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v7]
In-Reply-To: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
Message-ID: <CLwAlismI2wtJsh-HehkX2zXOKwg4meaRB6y3ONKXGU=.c00f76bf-e77d-4003-a925-d9def59ad2f8@github.com>

> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
> 
> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
> 
> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
> 
> The location should be zero for JNI access.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  renamed methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27584/files
  - new: https://git.openjdk.org/jdk/pull/27584/files/5fd78080..904bb397

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27584&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27584&range=05-06

  Stats: 556 lines in 4 files changed: 284 ins; 272 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27584/head:pull/27584

PR: https://git.openjdk.org/jdk/pull/27584

From lmesnik at openjdk.org  Sat Oct 25 02:00:48 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Oct 2025 02:00:48 GMT
Subject: RFR: 8224852: JVM crash on watched field access from native code
 [v8]
In-Reply-To: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
References: <12IGB4k1Yq9C_OPIrSyOReqbaELji2YIG5JxFB1BvG0=.6409bb87-5f4e-40e7-a1b0-11d571139612@github.com>
Message-ID: <dJp1u1kqPYIn6jqr5r9xhri1H9g9MNwDuOJyvrjFjOs=.91f3db4b-68d3-4e4b-ba41-61c5dbc26028@github.com>

> The field access/modification events set interp only mode and compiled frame is not expected. However JNI might call `post_field_access_by_jni` while the last java frame is compiled. 
> 
> 1) The thread switched to interponly mode while it is in JNI code. The deoptimization is triggered but each frame is really changed only execution returns to it.  So last java frame was not executed and thus is still compiled. 
> 2) The JNI accessed field from the thread where field events are not enabled. So the `post_field_access_by_jni` is called in threads in interp_only mode. 
> 
> The original example doesn't reproduce issue because of JDK changes and I don't know of it is 1) or 2)I. I implemented regression test for both problems. 
> 
> The location should be zero for JNI access.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  counter are updated

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27584/files
  - new: https://git.openjdk.org/jdk/pull/27584/files/904bb397..423f5b13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27584&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27584&range=06-07

  Stats: 15 lines in 2 files changed: 2 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27584/head:pull/27584

PR: https://git.openjdk.org/jdk/pull/27584

From duke at openjdk.org  Sat Oct 25 02:53:02 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:02 GMT
Subject: Withdrawn: 8368695: Support 101 switching protocol in jdk.httpserver
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <xzMm3alltKr_uQFUr-WnPiY0p0n-oXxvx0JY9OcrdHc=.8e9e00b5-731a-41e4-9fe2-68bca97f4413@github.com>

On Fri, 10 Oct 2025 19:45:57 GMT, Josiah Noel <duke at openjdk.org> wrote:

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/27751

From duke at openjdk.org  Sat Oct 25 02:53:01 2025
From: duke at openjdk.org (Josiah Noel)
Date: Sat, 25 Oct 2025 02:53:01 GMT
Subject: RFR: 8368695: Support 101 switching protocol in jdk.httpserver
 [v13]
In-Reply-To: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
References: <jqaoo-y9x2KdrmRPCKDZFdxqR11zZtzGETP0aR1dYt0=.3ee42f77-6fb6-438f-932a-84d29bf53389@github.com>
Message-ID: <QBwjoRxK6LU0NYy3le6TAPBxXOQ3wd3Cd2AYVzLMq6w=.65496765-65ef-471b-ac18-7cdd8d6c72b9@github.com>

> - adds a flag to ExchangeImpl to signal whether the current request is an Upgrade request
> - Adds a new `UpgradeInputStream` to ensure that the server keeps track of when the upgraded request is closed
> - on 101 response codes, `sendResponseHeaders` will not immediately close the output stream 
> - on 101 response codes, `sendResponseHeaders` will use an `UndefLengthOutputStream`

Josiah Noel has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Update ExchangeImpl.java
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - reduce diff
 - Merge remote-tracking branch 'upstream/master' into JDK-8368695
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - Update SwitchingProtocolTest.java
 - add exception test
 - Create UpgradeOutputStream.java
 - close raw streams
 - ... and 8 more: https://git.openjdk.org/jdk/compare/32697bf6...ae2b1184

-------------

Changes: https://git.openjdk.org/jdk/pull/27751/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27751&range=12
  Stats: 25304 lines in 632 files changed: 6529 ins; 14641 del; 4134 mod
  Patch: https://git.openjdk.org/jdk/pull/27751.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27751/head:pull/27751

PR: https://git.openjdk.org/jdk/pull/27751

From ysuenaga at openjdk.org  Sat Oct 25 02:53:19 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 25 Oct 2025 02:53:19 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v4]
In-Reply-To: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
Message-ID: <DRPW__6H3gRZ7wwVqpsitLc5yCLPCk489HG6qtFf304=.7ae3dc72-bf03-4733-a1eb-cdfa9734630e@github.com>

> `jhsdb jstack --mixed` would not work when attaches to the process runs with `-Xcomp`.
> 
> It has been reported by @pchilano in #27728. You can reproduce the problem with [Test.java (attached JBS)](https://bugs.openjdk.org/secure/attachment/116551/Test.java). You can see following stack.
> 
> 
> ----------------- 646689 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f1cec18c890 nid=646689 waiting on condition [0x00007f1cd0158000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f1cf3b7f462 __syscall_cancel_arch + 0x32
> 0x00007f1cf3b7375c __internal_syscall_cancel + 0x5c
> 0x00007f1cf3b766a8 ___pthread_cond_timedwait + 0x178
> 0x00007f1cf270e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f1cf2005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f1cf218789f JVM_SleepNanos + 0x28f
> 0x00007f1cdb95f299 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 
> 
> `Thread.sleepNanos0` is the bottom stack, but actually it has more call frames. You can see them with `-XX:+PreserveFramePointer`.
> 
> 
> ----------------- 646841 -----------------
> "Thread-0" #24 prio=5 tid=0x00007f4a0018c9e0 nid=646841 waiting on condition [0x00007f49e4fd7000]
>    java.lang.Thread.State: TIMED_WAITING (sleeping)
>    JavaThread state: _thread_blocked
> 0x00007f4a0aa29462 __syscall_cancel_arch + 0x32
> 0x00007f4a0aa1d75c __internal_syscall_cancel + 0x5c
> 0x00007f4a0aa206a8 ___pthread_cond_timedwait + 0x178
> 0x00007f4a0970e1e9 PlatformEvent::park_nanos(long) + 0x119
> 0x00007f4a09005f4c JavaThread::sleep_nanos(long) + 0xfc
> 0x00007f4a0918789f JVM_SleepNanos + 0x28f
> 0x00007f49ef961099 java.lang.Thread.sleepNanos0(long) + 0x99 (Native method)
> 0x00007f49e7f477b4 * java.lang.Thread.sleepNanos(long) bci:33 line:509 (Compiled frame)
> 0x00007f49e7f41a64 * java.lang.Thread.sleep(long) bci:25 line:540 (Compiled frame)
> 0x00007f49e7f4037c * Test.run() bci:3 line:6 (Compiled frame)
> 0x00007f49ef943328 * java.lang.Thread.runWith(java.lang.Object, java.lang.Runnable) bci:5 line:1487 (Compiled frame)
>                         * java.lang.Thread.run() bci:19 line:1474 (Compiled frame)
> 0x00007f49ef3385fd <StubRoutines (initial stubs)>
> 0x00007f4a08fc247e JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, JavaThread*) + 0x4ce
> 0x00007f4a08fc2bb3 JavaCalls::call_virtual(JavaValue*, Klass*, Symbol*, Symbol*, JavaCallArguments*, JavaThread*) + 0x2d3
> 0x00007f4a08fc31bb JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, JavaThread*) + 0xab
> 0x00007f4a091...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Add glibc version check to TestJhsdbJstackMixedWithXComp.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27885/files
  - new: https://git.openjdk.org/jdk/pull/27885/files/0e7c4ccd..434e8d28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27885&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27885&range=02-03

  Stats: 62 lines in 1 file changed: 61 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27885.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27885/head:pull/27885

PR: https://git.openjdk.org/jdk/pull/27885

From ysuenaga at openjdk.org  Sat Oct 25 02:58:04 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 25 Oct 2025 02:58:04 GMT
Subject: RFR: 8370176: Mixed mode jhsdb jstack cannot unwind call stack
 with -Xcomp [v2]
In-Reply-To: <Z6eMslS_-h_ZW35HOLVeyDkguCTBpNxhi9uvkmUvjOw=.7059f3bd-1f7e-4e30-b737-3d18d776fbe4@github.com>
References: <oHhzdW76h2FrGOsgfr-7qQYJGpyB6LI4ZSqti1FBMK4=.4868f712-aeef-4e88-824b-c9cd8d376fac@github.com>
 <r13EUkP_pIDEpo3mEnQyE7haphZTcnKhbWOG2wWoytI=.2f7b0215-a1ee-4fab-b310-bce5fbd2a512@github.com>
 <SY_UFpjdUUv7JinBUI9mXTmg2B3gbkHJ7-PjAY2aLMY=.b22d62d5-2b7a-4ab1-a5d0-a33cbcf05bde@github.com>
 <gwI0woqkZWDMZ_LcqgPq_Qg7Lx2K8a-Rs7QCB2vYoA8=.408fa778-bd14-43be-800d-a611abb9f0ce@github.com>
 <v2Z9hvERGo6HuvtNwV-rpMJtemhVlFMGONigQIlxf7Y=.53c6d597-5395-4e89-9515-065f8ac8ef73@github.com>
 <0bFZZSiXpHkkPDv4krxc6uW8ZA0NN4JW1EBwE3n4yWo=.983eba21-64ad-440e-8d78-36ba7fd1a4f9@github.com>
 <1pCb9jVqE1g4rIHCQTyUNU3HX1mm_30MI0Ux9_WyBD8=.31174776-e691-445b-b288-ba97272e637a@github.com>
 <VU0aXhIIV_c9P-QSAWP0hZMm9aNM1UsHrbsZbsKOy3A=.9041a0b4-1738-4264-a53d-b6829d685bd3@github.com>
 <-IavTMPm3hGAIFPYGYfO_H3-JtIrtfIsm_aRZkVlhsg=.1d7ffa01-9e29-4393-ae29-6a9b82b061bf@github.com>
 <jSS_0F3errESVqMQLqLBa2bCmwXN3fZlnmpr1qF0zOc=.3aa69838-bfca-402b-92d8-f57925cea9d9@github.com>
 <Z6eMslS_-h_ZW35HOLVeyDkguCTBpNxhi9u
 vkmUvjOw=.7059f3bd-1f7e-4e30-b737-3d18d776fbe4@github.com>
Message-ID: <aVgDvk5K7uXPO_J4_2SsDKqPUbCvtJP3Di6enGE6n5I=.b630f2f5-b7e6-47b3-aa3e-61af6b84b600@github.com>

On Fri, 24 Oct 2025 15:02:14 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> I could reproduce the problem not only Ubuntu 22.04 but also 23.04 . However it did not happen on Ubuntu 24.04 .
>> According to your report, the problem would happen on AArch64, it implies the problem is not in DWARF parser only. (DWARF parser is only available on Linux AMD64 so far)
>> 
>> AFAICS stack unwinding would fail from the function in glibc (on Ubuntu 22.04 and 23.04 at least), so I suspect something wrong in glibc binary and/or behavior and/or compiler options on Ubuntu. but I'm not sure.
>> 
>> I checked glibc version from `gnu_get_libc_version()`. "2.37" is returned on Ubuntu 23.04, and "2.39" is returned on Ubuntu 24.04 . So I think it can be `gnu_get_libc_version()` with FFM at first of the test, then the test is skipped if it runs on glibc 2.38 or earlier. Is it ok?
>> 
>> I grep'ed test directory with "mixed", I found another tests (TestJhsdbJstackMixed.java, TestJhsdbJstackPrintVMLocks.java). I will add glibc check to them as another ticket if this solution is ok.
>
> I am not sure about the glibc version as I don't know much about the differences among these distributions.
> But it works for me if you want to fix all the affected tests in another PR. Thanks for considering that.

I updated this PR to check glibc version in TestJhsdbJstackMixedWithXComp.java added by this PR. It skips the test on Ubuntu 22.04, OTOH it works on Fedora 43. It is expected.
I attempted to add this check to `SATestUtils` at first, but it seems to be difficult because native access have to be allowed all of `SATestUtils` users - the impact is too significant.

I will file another issue to apply this check to other tests of `jhsdb jstack --mixed` user after this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27885#discussion_r2462372806

From lmesnik at openjdk.org  Sat Oct 25 18:13:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Oct 2025 18:13:44 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
 [v2]
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <_dZqCSMdfrPcIOp7gcq08L9Mfk7p_GXOAD2oay0xbm4=.50fe9fc9-1411-4879-9e17-84b679dc0cd4@github.com>

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> Also, it would be useful to guarantee that VM_DEATH is last event so users can safely close/destroy all supported all structures used by Jvmti agent (like RawMonitors).
> 
> The proposed fix is to stop events posting and wait for already executing events before vm_death is posted.
> 
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

Leonid Mesnik 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 23 additional commits since the last revision:

 - fixed comments
 - fixed comments
 - cleanup
 - The global flag implemented
 - the post compiled method updated
 - added antoher transition
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8355631
 - better sync
 - restore eventmark
 - Revert "removed unused field"
   
   This reverts commit 379991eca4e54e1990ba2ade3d9a5c53d1f3657c.
 - ... and 13 more: https://git.openjdk.org/jdk/compare/c205be47...35b7c647

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27504/files
  - new: https://git.openjdk.org/jdk/pull/27504/files/b71ee9b9..35b7c647

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=00-01

  Stats: 163338 lines in 1904 files changed: 135305 ins; 18271 del; 9762 mod
  Patch: https://git.openjdk.org/jdk/pull/27504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27504/head:pull/27504

PR: https://git.openjdk.org/jdk/pull/27504

From lmesnik at openjdk.org  Sat Oct 25 18:13:44 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Oct 2025 18:13:44 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <bqrlt7PbRSSb2OO6Wk4ZIqq8oJkHg9fTwtmg-Nw5taA=.571b3370-d76c-4319-9d95-11d2bfff40fa@github.com>

On Thu, 25 Sep 2025 21:43:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> Also, it would be useful to guarantee that VM_DEATH is last event so users can safely close/destroy all supported all structures used by Jvmti agent (like RawMonitors).
> 
> The proposed fix is to stop events posting and wait for already executing events before vm_death is posted.
> 
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

I updated the fix and description to synchronize events posting during VM shutdown.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27504#issuecomment-3446990469

From lmesnik at openjdk.org  Sat Oct 25 18:27:39 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Oct 2025 18:27:39 GMT
Subject: RFR: 8355631: The events might be generated after VM_DEATH event
 [v3]
In-Reply-To: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
References: <-qGka2JsktkbQyA_l_1DG_zRfRmJe2hPEraSPltXmqY=.b4aeca47-9e15-417f-ae29-a1b885e07447@github.com>
Message-ID: <E0UEu0wiBicncqTfTSKk1iqJSNG6Ojg0hCXyC9L3ZNs=.925f9c73-3944-4c0d-aeca-1f87637484a6@github.com>

> The JVMTI spec says: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html#VMDeath
> `The VM death event notifies the agent of the termination of the VM. No events will occur after the VMDeath event.`
> 
> However, current implementation changes state and only after this start disabling events.  
> 
> It might be not a conformance issue, because there is no way to get thread state in the very beginning of event. 
> The main practical issue is that currently certain events are generated when VM is becoming dead. So any function in event should check error against JVMTI_PHASE_DEAD. We can easily trigger it by running tests with enabled https://bugs.openjdk.org/browse/JDK-8352654
> 
> Also, it would be useful to guarantee that VM_DEATH is last event so users can safely close/destroy all supported all structures used by Jvmti agent (like RawMonitors).
> 
> The proposed fix is to stop events posting and wait for already executing events before vm_death is posted.
> 
> Currently, I haven't seen problems with this fix and  https://bugs.openjdk.org/browse/JDK-8352654.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27504/files
  - new: https://git.openjdk.org/jdk/pull/27504/files/35b7c647..405d5a9c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27504&range=01-02

  Stats: 14 lines in 3 files changed: 0 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27504.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27504/head:pull/27504

PR: https://git.openjdk.org/jdk/pull/27504

From fandreuzzi at openjdk.org  Sat Oct 25 19:35:07 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 25 Oct 2025 19:35:07 GMT
Subject: RFR: 8370636: com/sun/jdi/TwoThreadsTest.java should wait for
 completion of all threads
In-Reply-To: <EhmvvLRP_Wn5V9UtYwoN-1yt-WWgScrT7gnon7ExxRg=.0ff62f59-a89a-4866-b050-3d77ef7ef0ce@github.com>
References: <EhmvvLRP_Wn5V9UtYwoN-1yt-WWgScrT7gnon7ExxRg=.0ff62f59-a89a-4866-b050-3d77ef7ef0ce@github.com>
Message-ID: <yZHPSc3U0FyECRsHR_PZXeiY26HNhD-_Jt9c7pKaqlU=.9d35a81c-5ce7-4744-829e-e3897fa4792b@github.com>

On Fri, 24 Oct 2025 20:20:14 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test 
> com/sun/jdi/TwoThreadsTest.java 
> start new threads using DebuggeeWrapper.newThread()
> and exit immediately.
> 
> It is needed to jon() threads so test really works for virtual threads.
> 
> I looked on other threads that use DebuggeeWrapper.newThread(). Seems most of them already updated to join spawned threads.
> 
> Tested by running test on all platfrom with and wihtout virtual threads.

test/jdk/com/sun/jdi/TwoThreadsTest.java line 58:

> 56:         t1.start();
> 57:         t2.start();
> 58:         // The threads might be virutal and daemon, so wait until completion.

Suggestion:

        // The threads might be virtual and daemon, so wait until completion.

test/jdk/com/sun/jdi/TwoThreadsTest.java line 62:

> 60:             t1.join();
> 61:             t2.join();
> 62:         } catch (InterruptedException e) {

Since anyway you're just wrapping the exception, perhaps adding `throws InterruptedException` to `main` would achieve the same effect?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27982#discussion_r2463007176
PR Review Comment: https://git.openjdk.org/jdk/pull/27982#discussion_r2463007541

From kdnilsen at openjdk.org  Sun Oct 26 00:00:03 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 26 Oct 2025 00:00:03 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v33]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <32pNJLsvsTHcyUfKjADbM-t7phkQt6ZkHUzaztBy4pg=.d7ed6aac-b88f-4ca5-8487-e44884ffaf17@github.com>

> This PR eliminates redundant bookkeeping that had been carried out by both ShenandoahGeneration and ShenandoahFreeSet.  In the new code, we keep a single tally of relevant information within ShenandoahFreeSet.
> Queries serviced by ShenandoahGeneration are now delegated to ShenandoahFreeSet.
> 
> This change eliminates rare and troublesome assertion failures that were often raised when the ShenandoahFreeSet tallies did not match the ShenandoahGeneration tallies.  These assertion failures resulted because the two sets of books are updated at different times, using different synchronization mechanisms.
> 
> The other benefit of this change is that we have less synchronization overhead because we only have to maintain a single set of books.

Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:

  reviewer feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/abf9b1f8..5557ae9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=31-32

  Stats: 6 lines in 1 file changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/26867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26867/head:pull/26867

PR: https://git.openjdk.org/jdk/pull/26867

From aph at openjdk.org  Sun Oct 26 08:43:11 2025
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 26 Oct 2025 08:43:11 GMT
Subject: RFR: 8365932: Implementation of JEP 516: Ahead-of-Time Object
 Caching with Any GC [v10]
In-Reply-To: <WWEn55PY-r6nrUD__Pk788lyspszX1BoL5lLCCPaYOY=.5b2026eb-a03d-4d01-a577-9b1d25eacca5@github.com>
References: <e6YN9cccpCw5HjJhI_-KX1naIT4py_Isj0oZrGc7gqI=.ed1b5c95-cb4c-4810-8a11-421882f4e790@github.com>
 <WWEn55PY-r6nrUD__Pk788lyspszX1BoL5lLCCPaYOY=.5b2026eb-a03d-4d01-a577-9b1d25eacca5@github.com>
Message-ID: <U10OXDO0_9UqgPkByQlwg-TwT3vU31hDCFw8UM8a_TI=.929d4a6f-4e4c-4d20-a33a-2adf56775e3d@github.com>

On Fri, 24 Oct 2025 20:11:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> This is the implementation of JEP 516: Ahead-of-Time Object Caching with Any GC.
>> 
>> The current mechanism for the AOT cache to cache heap objects is by using mmap to place bytes from a file directly in the GC managed heap. This mechanism poses compatibility challenges that all GCs have to have bit by bit identical object and reference formats, as the layout decisions are offline. This has so far meant that AOT cache optimizations requiring heap objects are not available when using ZGC. This work ensures that all GCs, including ZGC, are able to use the more advanced AOT cache functionality going forward.
>> 
>> This JEP introduces a new mechanism for archiving a primordial heap, without such compatibility problems. It embraces online layouts and allocates objects one by one, linking them using the Access API, like normal objects. This way, archived objects quack like any other object to the GC, and the GC implementations are decoupled from the archiving mechanism.
>> 
>> The key to doing this GC agnostic object loading is to represent object references between objects as object indices (e.g. 1, 2, 3) instead of raw pointers that we hope all GCs will recognise the same. These object indices become the key way of identifying objects. One table maps object indices to archived objects, and another table maps object indices to heap objects that have been allocated at runtime. This allows online linking of the materialized heap objects.
>> 
>> The main interface to the cached heap is roots. Different components can register object roots at dump time. Each root gets assigned a root index. At runtime, requests can be made to get a reference to an object at a root index. The new implementation uses lazy materialization and concurrency. When a thread asks for a root object, it must ensure that the given root object and its transitively reachable objects are reachable. A new background thread called the AOTThread, tries to perform the bulk of the work, so that the startup impact of processing the objects one by one is not impacting the bootstrapping thread.
>> 
>> Since the background thread performs the bulk of the work, the archived is laid out to ensure it can run as fast as possible.
>> Objects are laid out inf DFS pre order over the roots in the archive, such that the object indices and the DFS traversal orders are the same. This way, the DFS traversal that the background thread is performing is the same order as linearly materializing the objects one by one in the or...
>
> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Missing unlock diagnostic VM options, and remove unintended comment
>  - Fix for minimal
>  - Change streaming/mapping states to be binary instead of tri states
>  - Clean up VMProps
>  - Make AOTStreamableObjects diagnostic
>  - Test polishing
>  - Merge branch 'master' into 8326035_JEP_object_streaming_v6
>  - Test fix
>  - move exception marks outside locks
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/97e5ac6e...3d771ca2

Can you talk a little bit about the cost of doing all this? There's something superficially attractive about simply mapping the heap into memory at startup time. Will that continue to be an option with some GCs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27732#issuecomment-3448210742